thread scheduling priority with libkse

[Petri Helenius]

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.

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.

Pete