Date: Thu, 12 Nov 2009 22:50:21 +0300 From: Igor Sysoev <is@rambler-co.ru> To: Matthew Fleming <matthew.fleming@isilon.com> Cc: freebsd-stable@freebsd.org Subject: Re: 8.0RC2 "top" statistics seem broken Message-ID: <20091112195020.GC40464@rambler-co.ru> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E0338FEB8@seaxch09.desktop.isilon.com> References: <hdc0sp$br4$1@ger.gmane.org> <20091112071618.GB81250@rambler-co.ru> <06D5F9F6F655AD4C92E28B662F7F853E0338FEB8@seaxch09.desktop.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
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/
--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=koi8-r
Content-Disposition: attachment; filename="patch.ule"
--- 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.
--zhXaljGHf11kAtnf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091112195020.GC40464>