From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 12:57:16 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 D5AB1106566B; Tue, 14 Dec 2010 12:57:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A7FE78FC18; Tue, 14 Dec 2010 12:57:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6111B46B03; Tue, 14 Dec 2010 07:57:16 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4AF128A01D; Tue, 14 Dec 2010 07:57:15 -0500 (EST) From: John Baldwin To: David Xu Date: Tue, 14 Dec 2010 07:56:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012101050.45214.jhb@freebsd.org> <201012130927.26815.jhb@freebsd.org> <4D06C8B0.1060409@freebsd.org> In-Reply-To: <4D06C8B0.1060409@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012140756.52926.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 14 Dec 2010 07:57:15 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx 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 12:57:17 -0000 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