From owner-freebsd-arch@FreeBSD.ORG Sat Dec 11 21:39: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 A4A171065674 for ; Sat, 11 Dec 2010 21:39:23 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD148FC08 for ; Sat, 11 Dec 2010 21:39:22 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oBBLdKC6021815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Dec 2010 08:39:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id oBBLdIuA086414; Sun, 12 Dec 2010 08:39:18 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id oBBLdI4D086413; Sun, 12 Dec 2010 08:39:18 +1100 (EST) (envelope-from peter) Date: Sun, 12 Dec 2010 08:39:18 +1100 From: Peter Jeremy To: John Baldwin Message-ID: <20101211213918.GB21959@server.vk2pj.dyndns.org> References: <201012101050.45214.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <201012101050.45214.jhb@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) 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: Sat, 11 Dec 2010 21:39:23 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Dec-10 10:50:45 -0500, John Baldwin wrote: >The problem I am running into is that when a time-sharing thread goes to s= leep=20 >in the kernel (waiting on select, socket data, tty, etc.) it actually ends= up=20 >in the kernel priorities range (64 - 127). This means when it wakes up it= =20 >will trump (and preempt) a real-time user thread even though these process= es=20 >nominally have a priority down in the 160 - 223 range. We do drop the ker= nel=20 >sleep priority during userret(), but we don't recheck the scheduler queues= to=20 >see if we should preempt the thread during userret(), so it effectively ru= ns=20 >with the kernel sleep priority for the rest of the quantum while it is in= =20 >userland. This may also explain the situation I'm seeing where idprio processes are receiving more than "idle" time (see "idprio processes slowing down system" in -hackers). >My first question is if this behavior is the desired behavior? Originally= I=20 >think I preferred the current layout because I thought a thread in the ker= nel=20 >should always have priority so it can release locks, etc. I suspect it was intended as a solution to priority inversion issues. >1) (easy) just move the real-time priority range above the kernel sleep=20 >priority range This won't affect the associated issue of idprio processes "preempting" timesharing processes. >2) (harder) make sched_userret() check the run queue to see if it should= =20 >preempt when dropping the kernel sleep priority. IMHO, this is the "correct" solution but that needs to be tempered by the additional overhead this might incur. --=20 Peter Jeremy --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk0D74YACgkQ/opHv/APuIcROACeNr2ajW+rBdeMeZ+kVJAJoftB xtMAnAv9ZBzEYKvf/r67onBgf/dNZhGl =6FHd -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--