Date: Wed, 30 Apr 2008 14:26:39 -0700 From: Julian Elischer <julian@elischer.org> To: "Murty, Ravi" <ravi.murty@intel.com> Cc: freebsd-hackers@freebsd.org Subject: Re: maybe_preempt_in_ksegrp Message-ID: <4818E40F.9070004@elischer.org> In-Reply-To: <AEBCFC23C0E40949B10BA2C224FC61B007175275@orsmsx416.amr.corp.intel.com> References: <AEBCFC23C0E40949B10BA2C224FC61B007175275@orsmsx416.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Murty, Ravi wrote: > Hello All, > > > > Looking through the scheduler code (kern_switch.c) and two functions > that stood out were the following: > > > > 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. While "I" am higher than others in the kse group, I may not be the highest thread avalable in the system. (at least that is my recollection without going to check out a 6.x tree to look back at it.. My memory is that it just placed itself on the KSEG's run queue. If it thinks that it doesn't have a chance of running it doesn't bother to even try to get scheduled, but if it thinks it might, then it asks for the scheduler to re-evaluate. > 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. possibly. you could try it to see if it makes a difference. This code was all removed in 7.x It was never completed Why are you studying 6.x? I asked you this before but I forgot the answer :-) > 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? Paranoia and history. > > > > Thanks > > Ravi Murty > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4818E40F.9070004>