Realtime thread priorities

Peter Jeremy peterjeremy at
Sat Dec 11 21:39:23 UTC 2010

On 2010-Dec-10 10:50:45 -0500, John Baldwin <jhb at> wrote:
>The problem I am running into is that when a time-sharing thread goes to sleep 
>in the kernel (waiting on select, socket data, tty, etc.) it actually ends up 
>in the kernel priorities range (64 - 127).  This means when it wakes up it 
>will trump (and preempt) a real-time user thread even though these processes 
>nominally have a priority down in the 160 - 223 range.  We do drop the kernel 
>sleep priority during userret(), but we don't recheck the scheduler queues to 
>see if we should preempt the thread during userret(), so it effectively runs 
>with the kernel sleep priority for the rest of the quantum while it is in 

This may also explain the situation I'm seeing where idprio processes
are receiving more than "idle" time (see "idprio processes slowing
down system" in -hackers).

>My first question is if this behavior is the desired behavior?  Originally I 
>think I preferred the current layout because I thought a thread in the kernel 
>should always have priority so it can release locks, etc.

I suspect it was intended as a solution to priority inversion issues.

>1) (easy) just move the real-time priority range above the kernel sleep 
>priority range

This won't affect the associated issue of idprio processes "preempting"
timesharing processes.

>2) (harder) make sched_userret() check the run queue to see if it should 
>preempt when dropping the kernel sleep priority.

IMHO, this is the "correct" solution but that needs to be tempered by
the additional overhead this might incur.

Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the freebsd-arch mailing list