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 "[EMAIL PROTECTED]"

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to