Realtime thread priorities

[Peter Jeremy]

On 2010-Dec-10 10:50:45 -0500, John Baldwin <jhb at freebsd.org> 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 
>userland.

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 : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101211/dbaaa746/attachment.pgp