Date: Wed, 21 Nov 2007 18:41:31 -0800 From: "Kip Macy" <kip.macy@gmail.com> To: "Daniel Eischen" <deischen@freebsd.org> Cc: David Xu <davidxu@freebsd.org>, current@freebsd.org Subject: Re: strange thread priority displayed in top Message-ID: <b1fa29170711211841l2b5a1579ga0a2f724a7c9d51a@mail.gmail.com> In-Reply-To: <Pine.GSO.4.64.0711210901570.17756@sea.ntplx.net> References: <4743F1F7.2030709@freebsd.org> <Pine.GSO.4.64.0711210901570.17756@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 21, 2007 6:10 AM, Daniel Eischen <deischen@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170711211841l2b5a1579ga0a2f724a7c9d51a>