Date: Wed, 30 Apr 2008 14:35:54 -0700 From: "Murty, Ravi" <ravi.murty@intel.com> To: "Julian Elischer" <julian@elischer.org> Cc: freebsd-hackers@freebsd.org Subject: RE: maybe_preempt_in_ksegrp Message-ID: <AEBCFC23C0E40949B10BA2C224FC61B0071752E1@orsmsx416.amr.corp.intel.com> In-Reply-To: <4818E40F.9070004@elischer.org> References: <AEBCFC23C0E40949B10BA2C224FC61B007175275@orsmsx416.amr.corp.intel.com> <4818E40F.9070004@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian, Apologies for sticking to 6.x, I checked and looks like this function and several others are out in 7.x. It's just that we've been using 6.x for a while and continue to look at it. :) Coming back, I was thinking of the problem the other way around. The thread gets put on the ksegrp runq, but we don't know if it gets put at the head of the queue. All we know is we either find a slot or not. If we do, great sched_add is called which will add it to a CPU runq and check if it can preempt some thread on the target CPU. If we can't find a slot, it checks if it can steal (preempt) some other thread (of the same ksegrp) from a cpu. Let's consider the UP case to keep this simple. One of the checks is the priority of the newly runnable thread and the curthread on the CPU and the fact that they are part of the same KSEGRP. If both pass, I think it should say "run me" since we just established that I am higher priority than what's running on the CPU. Ravi -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Wednesday, April 30, 2008 2:27 PM To: Murty, Ravi Cc: freebsd-hackers@freebsd.org Subject: Re: maybe_preempt_in_ksegrp Murty, Ravi wrote: > Hello All, >=20 > =20 >=20 > Looking through the scheduler code (kern_switch.c) and two functions > that stood out were the following: >=20 > =20 >=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. While "I" am higher than others in the kse group, I may not be the=20 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=20 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=20 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. >=20 > =20 >=20 > Thanks >=20 > Ravi Murty >=20 > _______________________________________________ > 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?AEBCFC23C0E40949B10BA2C224FC61B0071752E1>