Re: strange thread priority displayed in top

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