Re: maybe_preempt_in_ksegrp

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

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

Relevant Pages

  • Re: Comments on the KSE option
    ... A naive scheduler would give you 1000 cpu slots and me 1. ... The fairness algorythm that you have made 'optional' is a very crude one and I had thought that by now someone would have written a better one, ... If it is made a project goal that threads should be unfair, ... work only to discover at the end that it is the only thread on the ksegrp, and therefore always eligible to run). ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... The aim of the fair scheduling code is to ensure that if you, as a user, ... A naive scheduler would give you 1000 cpu slots and me 1. ... I removed creating multiple threads in same ksegrp because the ksegrp ... The ksegrp provided fairness is very naive since I saw weired behavior ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... The aim of the fair scheduling code is to ensure that if you, as a user, ... A naive scheduler would give you 1000 cpu slots and me 1. ... I note that David recently disabled the fair ... I found I must throw away the ksegrp. ...
    (freebsd-current)
  • Re: More ULE bugs fixed.
    ... cleaning up the scheduler interface a bit.. ... In KSE there are a variable ... KSE-1:1 runs with a KSEGRP with a concurrancy of 1 per thread. ...
    (freebsd-current)
  • maybe_preempt_in_ksegrp
    ... The second parameter is NULL. ... it expects sched_choose to pick a thread from the ksegrp. ... expected it to say "I am preempting curthread because I am in the same ...
    (freebsd-hackers)