From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 14:38:17 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 4F59410656AB for ; Mon, 13 Dec 2010 14:38:17 +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 1F9948FC29 for ; Mon, 13 Dec 2010 14:38:17 +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 BEFE146B35; Mon, 13 Dec 2010 09:38:16 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F39648A01D; Mon, 13 Dec 2010 09:38:15 -0500 (EST) From: John Baldwin To: Sergey Babkin Date: Mon, 13 Dec 2010 09:27:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012101050.45214.jhb@freebsd.org> <4D052B3C.29454AC@verizon.net> In-Reply-To: <4D052B3C.29454AC@verizon.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012130927.26815.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 13 Dec 2010 09:38:16 -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 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: Mon, 13 Dec 2010 14:38:17 -0000 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