Realtime thread priorities

[John Baldwin]

On Saturday, December 11, 2010 4:39:18 pm Peter Jeremy wrote:
> 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).

Yes, this likely does explain that.  We could fix that for just idle priority
class threads in sched_userret() easily enough (just call mi_switch() if
td->td_pri_class == PRI_CLASS_IDLE).

> >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.

The other concern (and reason I lean towards 1) is that this is also a
feature that we depend on to favor interactive threads over compute-bound
threads.

-- 
John Baldwin