From owner-freebsd-current@FreeBSD.ORG Wed Nov 21 14:10:50 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 975B616A418; Wed, 21 Nov 2007 14:10:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D9C1D13C4C4; Wed, 21 Nov 2007 14:10:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id lALEAlTo019011; Wed, 21 Nov 2007 09:10:47 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 21 Nov 2007 09:10:48 -0500 (EST) Date: Wed, 21 Nov 2007 09:10:47 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <4743F1F7.2030709@freebsd.org> Message-ID: References: <4743F1F7.2030709@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: strange thread priority displayed in top X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 14:10:50 -0000 On Wed, 21 Nov 2007, David Xu wrote: > It seems top displaying thread priority in kernel strangely. > Look at threads blocked at select() syscall, it is displayed as 96, > it is userland priority: 96 + PZERO = 180. > > --- > last pid: 4352; load averages: 0.00, 0.11, 0.08 > up 0+00:06:24 16:40:03 > 138 processes: 2 running, 136 sleeping > CPU states: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle > Mem: 202M Active, 100M Inact, 129M Wired, 4824K Cache, 159M Buf, 559M Free > Swap: 2020M Total, 2020M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1075 davidxu 2 -8 0 53920K 25432K piperd 0 0:01 1.03% > gnome-terminal > 1020 davidxu 1 96 0 35048K 16344K CPU1 1 0:05 0.00% Xorg > 626 _tor 1 4 0 17256K 11492K kqread 1 0:02 0.00% tor > 1052 davidxu 1 96 0 58916K 27988K select 0 0:01 0.00% nautilus > 1053 davidxu 1 96 0 39368K 22504K select 1 0:01 0.00% > gnome-panel > 1070 davidxu 1 96 0 39416K 21476K select 0 0:01 0.00% > mixer_applet2 > 1061 davidxu 1 96 0 37692K 20716K select 1 0:00 0.00% > wnck-applet > > --- > > I think the problem is select() uses cv_wait_sig which does not raise > thread priority, but cv_broadcast() has a priority parameter to > raise thread's priorities, however cv_signal() does not have this > parameter, these are inconsitent interfaces. To fix the problem, there > are two ways: > 1. pass a priority parameter to cv_init(), and cv_wait(), cv_wait_sig() > etcs will use the priority, remove priority parameter from > cv_broadcast(). > > 2. pass a priority parameter to cv_wait(), and cv_wait_sig() etcs. > > I prefer the first one. I agree, the mistakes of msleep() and tsleep() shouldn't be propagated to cv's and mutexes. The priority should either be inherent in the mutex or cv, or in the thread if not present in the former. Solaris seems to do it this way in their kernel mutexes by initializing optionally with an interrupt cookie (mmm, cookie) for mutexes used within interrupt handlers. -- DE