Realtime thread priorities

[David Xu]

John Baldwin wrote:
> 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.

I have requirement to make a thread running in kernel has more higher
priority over a thread running userland code, because our kernel
mutex is not sleepable which does not like Solaris did, I have to use
semaphore like code in kern_umtx.c to lock a chain, which allows me
to read and write user address space, this is how umtxq_busy() did,
but it does not prevent a userland thread from preempting a thread
which locked the chain, if a realtime thread preempts a thread
locked the chain, it may lock up whole processes using pthread.
I think our realtime scheduling is not very useful, it is too easy
to lock up system.

Regards,
David Xu