8.0RC2 "top" statistics seem broken

[Ivan Voras-7]

Here is what I'm seeing now:


last pid: 70893;  load averages:  1.70,  1.10,  0.58
                                                             up
27+02:59:26  16:23:59
134 processes: 3 running, 131 sleeping
CPU: 94.8% user,  0.0% nice,  4.6% system,  0.6% interrupt,  0.0% idle
Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free
Swap: 640M Total, 205M Used, 435M Free, 32% Inuse

   PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   751 pgsql       1  45    0   159M   556K select 1 249:38  0.00% postgres
   756 pgsql       1  44    0 25004K   600K select 1  86:31  0.00% postgres
   754 pgsql       1  44    0   159M  1040K select 1  13:02  0.00% postgres
   753 pgsql       1  44    0   159M  7868K select 1  10:55  0.00% postgres
   597 root        1  44    0  3184K   464K select 0   4:49  0.00% syslogd
   755 pgsql       1  44    0   159M  1432K select 1   4:46  0.00% postgres
   659 root        1  44    0 62156K  1356K select 1   4:30  0.00%
vmware-guestd
   765 nobody      1   4    0  3236K   192K kqread 1   3:25  0.00% memcached
   775 root        1  44    0  9996K   340K select 1   2:18  0.00% httpd
   900 sveb        1   5    0  9452K     0K select 0   1:49  0.00% <sshd>
   790 www         1  44    0  9768K   224K select 1   1:47  0.00% httpd
70851 ivoras      3  96    0   199M   195M CPU0   0   1:47  0.00% 7z


Load average and %CPU user are right, as are other global statistics.
The load is produced by the "7z" process (archivers/p7zip) which
compresses some data in two threads but is credited with 0% CPU, though
its runtime is correct (increments every second as it should in a
CPU-bound process). It doesn't help if I expand / show individual threads.

_______________________________________________
freebsd-stable@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@..."

[Jeremy Chadwick]

On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote:

> Here is what I'm seeing now:
>
>
> last pid: 70893;  load averages:  1.70,  1.10,  0.58
> up 27+02:59:26  16:23:59
> 134 processes: 3 running, 131 sleeping
> CPU: 94.8% user,  0.0% nice,  4.6% system,  0.6% interrupt,  0.0% idle
> Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free
> Swap: 640M Total, 205M Used, 435M Free, 32% Inuse
>
>   PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>   751 pgsql       1  45    0   159M   556K select 1 249:38  0.00% postgres
>   756 pgsql       1  44    0 25004K   600K select 1  86:31  0.00% postgres
>   754 pgsql       1  44    0   159M  1040K select 1  13:02  0.00% postgres
>   753 pgsql       1  44    0   159M  7868K select 1  10:55  0.00% postgres
>   597 root        1  44    0  3184K   464K select 0   4:49  0.00% syslogd
>   755 pgsql       1  44    0   159M  1432K select 1   4:46  0.00% postgres
>   659 root        1  44    0 62156K  1356K select 1   4:30  0.00% vmware-guestd
>   765 nobody      1   4    0  3236K   192K kqread 1   3:25  0.00% memcached
>   775 root        1  44    0  9996K   340K select 1   2:18  0.00% httpd
>   900 sveb        1   5    0  9452K     0K select 0   1:49  0.00% <sshd>
>   790 www         1  44    0  9768K   224K select 1   1:47  0.00% httpd
> 70851 ivoras      3  96    0   199M   195M CPU0   0   1:47  0.00% 7z
>
>
> Load average and %CPU user are right, as are other global
> statistics. The load is produced by the "7z" process
> (archivers/p7zip) which compresses some data in two threads but is
> credited with 0% CPU, though its runtime is correct (increments
> every second as it should in a CPU-bound process). It doesn't help
> if I expand / show individual threads.

Does the behaviour change if you use "top -C" or "top -P" (doubting
the latter)?

--
| Jeremy Chadwick                                   jdc@... |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |
_______________________________________________
freebsd-stable@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@..."

[Ivan Voras-7]

Jeremy Chadwick wrote:

>
> On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote:
>> Here is what I'm seeing now:
>>
>>
>> last pid: 70893;  load averages:  1.70,  1.10,  0.58
>> up 27+02:59:26  16:23:59
>> 134 processes: 3 running, 131 sleeping
>> CPU: 94.8% user,  0.0% nice,  4.6% system,  0.6% interrupt,  0.0% idle
>> Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free
>> Swap: 640M Total, 205M Used, 435M Free, 32% Inuse
>>
>>   PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>>   751 pgsql       1  45    0   159M   556K select 1 249:38  0.00% postgres
>>   756 pgsql       1  44    0 25004K   600K select 1  86:31  0.00% postgres
>>   754 pgsql       1  44    0   159M  1040K select 1  13:02  0.00% postgres
>>   753 pgsql       1  44    0   159M  7868K select 1  10:55  0.00% postgres
>>   597 root        1  44    0  3184K   464K select 0   4:49  0.00% syslogd
>>   755 pgsql       1  44    0   159M  1432K select 1   4:46  0.00% postgres
>>   659 root        1  44    0 62156K  1356K select 1   4:30  0.00% vmware-guestd
>>   765 nobody      1   4    0  3236K   192K kqread 1   3:25  0.00% memcached
>>   775 root        1  44    0  9996K   340K select 1   2:18  0.00% httpd
>>   900 sveb        1   5    0  9452K     0K select 0   1:49  0.00% <sshd>
>>   790 www         1  44    0  9768K   224K select 1   1:47  0.00% httpd
>> 70851 ivoras      3  96    0   199M   195M CPU0   0   1:47  0.00% 7z
>>
>>
>> Load average and %CPU user are right, as are other global
>> statistics. The load is produced by the "7z" process
>> (archivers/p7zip) which compresses some data in two threads but is
>> credited with 0% CPU, though its runtime is correct (increments
>> every second as it should in a CPU-bound process). It doesn't help
>> if I expand / show individual threads.
>
> Does the behaviour change if you use "top -C" or "top -P" (doubting
> the latter)?

No, same in all cases.

_______________________________________________
freebsd-stable@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@..."

[Igor Sysoev]

On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote:

> Here is what I'm seeing now:
>
>
> last pid: 70893;  load averages:  1.70,  1.10,  0.58
>                                                              up
> 27+02:59:26  16:23:59
> 134 processes: 3 running, 131 sleeping
> CPU: 94.8% user,  0.0% nice,  4.6% system,  0.6% interrupt,  0.0% idle
> Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free
> Swap: 640M Total, 205M Used, 435M Free, 32% Inuse
>
>    PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>    751 pgsql       1  45    0   159M   556K select 1 249:38  0.00% postgres
>    756 pgsql       1  44    0 25004K   600K select 1  86:31  0.00% postgres
>    754 pgsql       1  44    0   159M  1040K select 1  13:02  0.00% postgres
>    753 pgsql       1  44    0   159M  7868K select 1  10:55  0.00% postgres
>    597 root        1  44    0  3184K   464K select 0   4:49  0.00% syslogd
>    755 pgsql       1  44    0   159M  1432K select 1   4:46  0.00% postgres
>    659 root        1  44    0 62156K  1356K select 1   4:30  0.00%
> vmware-guestd
>    765 nobody      1   4    0  3236K   192K kqread 1   3:25  0.00% memcached
>    775 root        1  44    0  9996K   340K select 1   2:18  0.00% httpd
>    900 sveb        1   5    0  9452K     0K select 0   1:49  0.00% <sshd>
>    790 www         1  44    0  9768K   224K select 1   1:47  0.00% httpd
> 70851 ivoras      3  96    0   199M   195M CPU0   0   1:47  0.00% 7z
>
>
> Load average and %CPU user are right, as are other global statistics.
> The load is produced by the "7z" process (archivers/p7zip) which
> compresses some data in two threads but is credited with 0% CPU, though
> its runtime is correct (increments every second as it should in a
> CPU-bound process). It doesn't help if I expand / show individual threads.

I believe this is related to multithreaded processes only. I saw this for
intr kernel process. Singlethread processes eat CPU slightly less than
on 7.2, however, I can not say is it statistic errors or real speedup.
I saw the issue on SMP/ULE only and can not say anything about UP and
4BSD scheduler.


--
Igor Sysoev
http://sysoev.ru/en/
_______________________________________________
freebsd-stable@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@..."

[Matthew Fleming]

> > [snip]
> >
> > Load average and %CPU user are right, as are other global
statistics.
> > The load is produced by the "7z" process (archivers/p7zip) which
> > compresses some data in two threads but is credited with 0% CPU,
though
> > its runtime is correct (increments every second as it should in a
> > CPU-bound process). It doesn't help if I expand / show individual
> threads.
>
> I believe this is related to multithreaded processes only. I saw this
for
> intr kernel process. Singlethread processes eat CPU slightly less than
> on 7.2, however, I can not say is it statistic errors or real speedup.
> I saw the issue on SMP/ULE only and can not say anything about UP and
> 4BSD scheduler.

Check out r197652 on stable/7.  I had a similar problem where top was
showing 0% for a CPU hog, but since I was unable to replicate it on
CURRENT (and the ULE accounting code is different between releases) I
only submitted for stable/7.  I think the patch will be easy to apply by
hand, though, to test it.

Thanks,
matthew

_______________________________________________
freebsd-stable@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@..."

[Igor Sysoev]

On Thu, Nov 12, 2009 at 08:42:28AM -0800, Matthew Fleming wrote:

> > > [snip]
> > >
> > > Load average and %CPU user are right, as are other global
> statistics.
> > > The load is produced by the "7z" process (archivers/p7zip) which
> > > compresses some data in two threads but is credited with 0% CPU,
> though
> > > its runtime is correct (increments every second as it should in a
> > > CPU-bound process). It doesn't help if I expand / show individual
> > threads.
> >
> > I believe this is related to multithreaded processes only. I saw this
> for
> > intr kernel process. Singlethread processes eat CPU slightly less than
> > on 7.2, however, I can not say is it statistic errors or real speedup.
> > I saw the issue on SMP/ULE only and can not say anything about UP and
> > 4BSD scheduler.
>
> Check out r197652 on stable/7.  I had a similar problem where top was
> showing 0% for a CPU hog, but since I was unable to replicate it on
> CURRENT (and the ULE accounting code is different between releases) I
> only submitted for stable/7.  I think the patch will be easy to apply by
> hand, though, to test it.

Thank you very much. I have applied your patch and it fixes the bug:

CPU 0: 22.0% user,  0.0% nice,  4.9% system,  0.0% interrupt, 73.2% idle
CPU 1:  1.2% user,  0.0% nice,  1.2% system,  4.9% interrupt, 92.7% idle

  PID USERNAME     THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root           2 171 ki31     0K    32K CPU0    0  12:11 165.77% idle
 1338 nobody         1  44  -10   439M   433M kqread  0   0:24 14.45% nginx
 1339 nobody         1  44  -10   439M   433M kqread  0   0:23 12.89% nginx
   12 root          15 -60    -     0K   240K WAIT    0   0:09  4.39% intr


CPU 0: 16.2% user,  0.0% nice,  8.5% system,  0.8% interrupt, 74.5% idle
CPU 1:  1.2% user,  0.0% nice,  1.9% system,  4.2% interrupt, 92.7% idle

  PID USERNAME    PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root        171 ki31     0K    32K RUN     1   6:39 88.96% {idle: cpu1}
   11 root        171 ki31     0K    32K RUN     0   6:11 77.59% {idle: cpu0}
 1338 nobody       44  -10   439M   433M CPU0    0   0:27 14.45% nginx
 1339 nobody       44  -10   439M   433M RUN     1   0:26 14.26% nginx
   12 root        -68    -     0K   240K WAIT    1   0:09  4.69% {irq19: bge0}

The patch against 8.0-PREREALSE is attached.


--
Igor Sysoev
http://sysoev.ru/en/

--- sys/kern/sched_ule.c 2009-11-02 09:25:28.000000000 +0300
+++ sys/kern/sched_ule.c 2009-11-12 21:53:45.000000000 +0300
@@ -103,6 +103,7 @@
  u_int ts_slptime; /* Number of ticks we vol. slept */
  u_int ts_runtime; /* Number of ticks we were running */
  int ts_ltick; /* Last tick that we were running on */
+ int ts_incrtick; /* Last tick that we incremented on */
  int ts_ftick; /* First tick that we were running on */
  int ts_ticks; /* Tick count */
 #ifdef KTR
@@ -1991,6 +1992,7 @@
  */
  ts2->ts_ticks = ts->ts_ticks;
  ts2->ts_ltick = ts->ts_ltick;
+ ts2->ts_incrtick = ts->ts_incrtick;
  ts2->ts_ftick = ts->ts_ftick;
  child->td_user_pri = td->td_user_pri;
  child->td_base_user_pri = td->td_base_user_pri;
@@ -2182,11 +2184,12 @@
  * Ticks is updated asynchronously on a single cpu.  Check here to
  * avoid incrementing ts_ticks multiple times in a single tick.
  */
- if (ts->ts_ltick == ticks)
+ if (ts->ts_incrtick == ticks)
  return;
  /* Adjust ticks for pctcpu */
  ts->ts_ticks += 1 << SCHED_TICK_SHIFT;
  ts->ts_ltick = ticks;
+ ts->ts_incrtick = ticks;
  /*
  * Update if we've exceeded our desired tick threshhold by over one
  * second.

_______________________________________________
freebsd-stable@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@..."