Date: Wed, 30 Apr 2008 14:11:32 -0700 From: "Murty, Ravi" <ravi.murty@intel.com> To: <freebsd-hackers@freebsd.org> Subject: maybe_preempt_in_ksegrp Message-ID: <AEBCFC23C0E40949B10BA2C224FC61B007175275@orsmsx416.amr.corp.intel.com>
next in thread | raw e-mail | index | archive | help
Hello All, =20 Looking through the scheduler code (kern_switch.c) and two functions that stood out were the following: =20 1. maybe_preempt_in_ksegrp - this function basically checks if the thread being made runnable should preempt another thread that is part of the same ksegrp. This makes sense. What I am having difficulty wrapping my brain around is the fact that if all checks pass, the kernel call mi_switch(SW_INVOL, NULL). The second parameter is NULL. This means that it expects sched_choose to pick a thread from the ksegrp. I would have expected it to say "I am preempting curthread because I am in the same ksegrp but higher priority, therefore switch to me".. the second parameter would have been td? When I compare this with what happens in mybe_preempt, the second parameter to mi_switch is the target thread because we're preempting the curthread (any ksegrp) to run the new thread. This makes sense. 2. Why do we check the state of the kse and make sure it is KES_THREAD. I would imagine that when this function is called, the state is exactly KES_THREAD? What am I missing here? =20 Thanks Ravi Murty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEBCFC23C0E40949B10BA2C224FC61B007175275>