Date: Tue, 14 Dec 2010 09:30:24 +0800 From: David Xu <davidxu@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, Sergey Babkin <babkin@verizon.net> Subject: Re: Realtime thread priorities Message-ID: <4D06C8B0.1060409@freebsd.org> In-Reply-To: <201012130927.26815.jhb@freebsd.org> References: <201012101050.45214.jhb@freebsd.org> <4D052B3C.29454AC@verizon.net> <201012130927.26815.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D06C8B0.1060409>