From owner-freebsd-current@FreeBSD.ORG Thu Nov 22 08:10:31 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 7484516A47A for ; Thu, 22 Nov 2007 08:10:31 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 63FAE13C4CC for ; Thu, 22 Nov 2007 08:09:44 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3243206waf for ; Thu, 22 Nov 2007 00:09:29 -0800 (PST) Received: by 10.114.190.6 with SMTP id n6mr318778waf.1195699291215; Wed, 21 Nov 2007 18:41:31 -0800 (PST) Received: by 10.114.13.15 with HTTP; Wed, 21 Nov 2007 18:41:31 -0800 (PST) Message-ID: Date: Wed, 21 Nov 2007 18:41:31 -0800 From: "Kip Macy" To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4743F1F7.2030709@freebsd.org> Cc: David Xu , 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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 08:10:31 -0000 On Nov 21, 2007 6:10 AM, Daniel Eischen wrote: > > 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. > This sounds like the right way to go. However, could we please wait until we hit 7.0-RELEASE to change the interface? -Kip