RE: 8.0RC2 top statistics seem broken
[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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0RC2 top statistics seem broken
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 SIZERES STATE C TIME WCPU COMMAND
11 root 2 171 ki31 0K32K CPU00 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 WAIT0 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 USERNAMEPRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root171 ki31 0K32K RUN 1 6:39 88.96% {idle: cpu1}
11 root171 ki31 0K32K RUN 0 6:11 77.59% {idle: cpu0}
1338 nobody 44 -10 439M 433M CPU00 0:27 14.45% nginx
1339 nobody 44 -10 439M 433M RUN 1 0:26 14.26% nginx
12 root-68- 0K 240K WAIT1 0:09 4.69% {irq19: bge0}
The patch against 8.0-PREREALSE is attached.
--
Igor Sysoev
http://sysoev.ru/en/
--- sys/kern/sched_ule.c2009-11-02 09:25:28.0 +0300
+++ sys/kern/sched_ule.c2009-11-12 21:53:45.0 +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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0RC2 top statistics seem broken
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 SIZERES STATE C TIME WCPU COMMAND 751 pgsql 1 450 159M 556K select 1 249:38 0.00% postgres 756 pgsql 1 440 25004K 600K select 1 86:31 0.00% postgres 754 pgsql 1 440 159M 1040K select 1 13:02 0.00% postgres 753 pgsql 1 440 159M 7868K select 1 10:55 0.00% postgres 597 root1 440 3184K 464K select 0 4:49 0.00% syslogd 755 pgsql 1 440 159M 1432K select 1 4:46 0.00% postgres 659 root1 440 62156K 1356K select 1 4:30 0.00% vmware-guestd 765 nobody 1 40 3236K 192K kqread 1 3:25 0.00% memcached 775 root1 440 9996K 340K select 1 2:18 0.00% httpd 900 sveb1 50 9452K 0K select 0 1:49 0.00% sshd 790 www 1 440 9768K 224K select 1 1:47 0.00% httpd 70851 ivoras 3 960 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0RC2 top statistics seem broken
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 SIZERES STATE C TIME WCPU COMMAND 751 pgsql 1 450 159M 556K select 1 249:38 0.00% postgres 756 pgsql 1 440 25004K 600K select 1 86:31 0.00% postgres 754 pgsql 1 440 159M 1040K select 1 13:02 0.00% postgres 753 pgsql 1 440 159M 7868K select 1 10:55 0.00% postgres 597 root1 440 3184K 464K select 0 4:49 0.00% syslogd 755 pgsql 1 440 159M 1432K select 1 4:46 0.00% postgres 659 root1 440 62156K 1356K select 1 4:30 0.00% vmware-guestd 765 nobody 1 40 3236K 192K kqread 1 3:25 0.00% memcached 775 root1 440 9996K 340K select 1 2:18 0.00% httpd 900 sveb1 50 9452K 0K select 0 1:49 0.00% sshd 790 www 1 440 9768K 224K select 1 1:47 0.00% httpd 70851 ivoras 3 960 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0RC2 top statistics seem broken
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 SIZERES STATE C TIME WCPU COMMAND 751 pgsql 1 450 159M 556K select 1 249:38 0.00% postgres 756 pgsql 1 440 25004K 600K select 1 86:31 0.00% postgres 754 pgsql 1 440 159M 1040K select 1 13:02 0.00% postgres 753 pgsql 1 440 159M 7868K select 1 10:55 0.00% postgres 597 root1 440 3184K 464K select 0 4:49 0.00% syslogd 755 pgsql 1 440 159M 1432K select 1 4:46 0.00% postgres 659 root1 440 62156K 1356K select 1 4:30 0.00% vmware-guestd 765 nobody 1 40 3236K 192K kqread 1 3:25 0.00% memcached 775 root1 440 9996K 340K select 1 2:18 0.00% httpd 900 sveb1 50 9452K 0K select 0 1:49 0.00% sshd 790 www 1 440 9768K 224K select 1 1:47 0.00% httpd 70851 ivoras 3 960 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 j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0RC2 top statistics seem broken
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 SIZERES STATE C TIME WCPU COMMAND 751 pgsql 1 450 159M 556K select 1 249:38 0.00% postgres 756 pgsql 1 440 25004K 600K select 1 86:31 0.00% postgres 754 pgsql 1 440 159M 1040K select 1 13:02 0.00% postgres 753 pgsql 1 440 159M 7868K select 1 10:55 0.00% postgres 597 root1 440 3184K 464K select 0 4:49 0.00% syslogd 755 pgsql 1 440 159M 1432K select 1 4:46 0.00% postgres 659 root1 440 62156K 1356K select 1 4:30 0.00% vmware-guestd 765 nobody 1 40 3236K 192K kqread 1 3:25 0.00% memcached 775 root1 440 9996K 340K select 1 2:18 0.00% httpd 900 sveb1 50 9452K 0K select 0 1:49 0.00% sshd 790 www 1 440 9768K 224K select 1 1:47 0.00% httpd 70851 ivoras 3 960 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
