From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 01:30:23 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D25D106566C; Tue, 14 Dec 2010 01:30:23 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E50F58FC16; Tue, 14 Dec 2010 01:30:22 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBE1ULlS013221; Tue, 14 Dec 2010 01:30:22 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D06C8B0.1060409@freebsd.org> Date: Tue, 14 Dec 2010 09:30:24 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: John Baldwin References: <201012101050.45214.jhb@freebsd.org> <4D052B3C.29454AC@verizon.net> <201012130927.26815.jhb@freebsd.org> In-Reply-To: <201012130927.26815.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Sergey Babkin Subject: Re: Realtime thread priorities X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 01:30:23 -0000 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