Re: Realtime thread priorities

On Monday, December 13, 2010 8:30:24 pm David Xu wrote:
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.

Users are not forced to use rtprio. They choose to do so, and they have to
be root to enable it (either directly or by extending root privileges via
sudo or some such). Just because you don't have a use case for it doesn't
mean that other people do not. Right now there is no way possible to say
that a given userland process is more important than 'sshd' (or any other
daemon) blocked in poll/select/kevent waiting for a packet. However, there
are use cases where other long-running userland processes are in fact far
more important than sshd (or similar processes such as getty, etc.).

--
John Baldwin
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Realtime thread priorities
    ... just move the real-time priority range above the kernel sleep ... locked the chain, it may lock up whole processes using pthread. ... running userland code will fix such a deadlock in kernel. ...
    (freebsd-arch)
  • Re: Realtime thread priorities
    ... just move the real-time priority range above the kernel sleep ... but it does not prevent a userland thread from preempting a thread ... locked the chain, it may lock up whole processes using pthread. ...
    (freebsd-arch)
  • Re: Realtime thread priorities
    ... just move the real-time priority range above the kernel sleep ... locked the chain, it may lock up whole processes using pthread. ... running userland code will fix such a deadlock in kernel. ...
    (freebsd-arch)
  • RE: [RFC/PATCH] FUSYN Realtime & Robust mutexes for Linux try 2
    ... > implementation can be moved from kernel space to userspace, ... - robustness: you need the kernel help, at least to identify the dead ... it can be dangerous to promote the priority of task B, ... it can do everything waitqueues do with the priority based interface. ...
    (Linux-Kernel)
  • Re: Realtime thread priorities
    ... just move the real-time priority range above the kernel sleep ... Note that timesharing threads are not "bumped" to a kernel sleep priority when they enter the kernel either. ... locked the chain, it may lock up whole processes using pthread. ...
    (freebsd-arch)