julian at elischer.org
Wed Apr 30 21:26:38 UTC 2008
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.
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
> 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.
> Ravi Murty
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers