strange thread priority displayed in top
Kip Macy
kip.macy at gmail.com
Thu Nov 22 00:10:31 PST 2007
On Nov 21, 2007 6:10 AM, Daniel Eischen <deischen at 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
More information about the freebsd-current
mailing list