Re: strange thread priority displayed in top

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