thread scheduling priority with libkse

[Daniel Eischen]

On Tue, 8 Jul 2003, Petri Helenius wrote:
> Daniel Eischen wrote:
> 
> >The current thread.  As I said before, if there are idle KSEs, then
> >one is woken to run the newly runnable thread.
> >
> I'm seeing about 200 microsecond latency when scheduling the thread on 
> the other
> KSE. Which translates to maximum of 2500  "spins"  of the contested loop 
> a second.

That's the time it takes for the KSE to be woken up in the
kernel and scheduled.

> Same code runs about 500000 spins  a second when no locking is involved.
> 
> This is on othervise idle Dual 2.4 Xeon.
>  
> If the mutex performance sounds about right, I need to redesign my 
> locking to
> go from one contested lock to many uncontested ones, which sounds a good 
> idea
> anyway.

> 
> >It waits until either you hit a blocking condition or the
> >quantum expires.  The library is not (yet) smart enough
> >to switch out the current thread after the unlock if the
> >new owner has a higher priority.  We could do that, but
> >if there are other KSEs that can run the new thread, then
> >they should get it.
> >
> >  
> >
> But the library is smart enough to extend the quantum on a higher
> priority thread if SCHED_RR is in effect? I'm seeing multiples
> of 20ms being allocated with two runnable threads of priorities
> 15 and 20 competing for the CPU.

A higher priority thread will always be run over a low
priority thread, regardless of quantum.  So yes, quantum
is continually extended as long as the thread remains
the highest priority thread and continues to be runnable.
The library currently uses 20msec for the round-robin
interval.

-- 
Dan Eischen