Realtime thread priorities

[John Baldwin]

On Sunday, December 12, 2010 3:06:20 pm Sergey Babkin wrote:
> John Baldwin wrote:
> > 
> > The current layout breaks up the global thread priority space (0 - 255) 
into a
> > couple of bands:
> > 
> >   0 -  63 : interrupt threads
> >  64 - 127 : kernel sleep priorities (PSOCK, etc.)
> > 128 - 159 : real-time user threads (rtprio)
> > 160 - 223 : time-sharing user threads
> > 224 - 255 : idle threads (idprio and kernel idle procs)
> > 
> > If we decide to change the behavior I see two possible fixes:
> > 
> > 1) (easy) just move the real-time priority range above the kernel sleep
> > priority range
> 
> Would not this cause a priority inversion when an RT process
> enters the kernel mode?

How so?  Note that timesharing threads are not "bumped" to a kernel sleep 
priority when they enter the kernel either.  The kernel sleep priorities are 
purely a way for certain sleep channels to cause a thread to be treated as 
interactive and give it a priority boost to favor interactive threads.  
Threads in the kernel do not automatically have higher priority than threads 
not in the kernel.  Keep in mind that all stopped threads (threads not 
executing) are always in the kernel when they stop.

-- 
John Baldwin