maybe_preempt_in_ksegrp

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"