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