top incorrectly reporting process time

[Ott Köstner]

Jeremy Chadwick wrote:
> On Sun, Nov 16, 2008 at 04:34:01PM +0200, Ott Köstner wrote:
>   
>> On several FreeBSD machines I have the following problem:
>>     
>
> What FreeBSD version?  (It matters)
>   
7.1-PRERELEASE FreeBSD

But I can experience it also on a 7.0 machine. Seems that top reports
incorrectly processes with multiple threads.

$ top -bUbind
last pid: 21635;  load averages:  0.73,  0.46,  0.29  up 1+00:17:18
16:48:10
54 processes:  1 running, 53 sleeping

Mem: 66M Active, 1174M Inact, 204M Wired, 36K Cache, 112M Buf, 555M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
  979 bind        8  44    0 40288K 32916K select 0   0:16  0.00% named

$ ps -ax|grep 979
  979  ??  Ss     1:11.26 /usr/sbin/named -n 5 -t /var/named -u bind


>   
>> # top -bUmysql
>> last pid: 99112;  load averages:  0.22,  0.12,  0.09  up 2+06:07:05
>> 16:17:43
>> 132 processes: 1 running, 131 sleeping
>>
>> Mem: 718M Active, 2494M Inact, 455M Wired, 77M Cache, 214M Buf, 213M Free
>> Swap: 4096M Total, 4096M Free
>>
>>
>>  PID USERNAME      THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU
>> COMMAND
>> 1079 mysql           9  20    0 81564K 60268K sigwai 1   0:01  0.00% mysqld
>>
>>
>> ^^^^^^^
>> ------------------------------------------------------------------------------------------------------------
>>
>> 1015 mysql           1   8    0  7056K  1368K wait   1   0:00  0.00% sh
>>
>>
>> However mysqld time is actually
>>
>> # ps -ax|grep mysql
>> 1015 con- I      0:00.01 /bin/sh /usr/local/bin/mysqld_safe
>> --defaults-extra-file=/var/db/mysql/my.cnf
>> 1079 con- S     70:03.64 [mysqld]
>>                       ^^^^^^^^^^^
>> ------------------------------------------------------------------------------------------------------------
>>
>> 99156  p0  S+     0:00.00 grep mysql
>>
>> Anyone who can explain this?
>>     
>
> Does the behaviour change if you mount /proc?  (This would mainly apply
> to RELENG_6 and earlier only)
>
>   
procfs on /proc (procfs, local)

No.