lkml.org 
[lkml]   [2001]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Weird vmstat reports in 2.2.18
On Sun, Jan 14, 2001 at 01:50:55AM -0500, Albert D. Cahalan wrote:
>
> > The report is like this:
> > #vmstat 1 60 | awk '{ print $16 }'
> > id
> > 0
> > 0
> > 20452224
> > 1
> > 20452224
> > 0
> > 1
> > 20452224
> > 1
> > 0
> > 0
> >
> > I wasnt able to trigger it in a predictable way, it just pops up...
>
> You should be able to trigger it by running something on both CPUs.
> Starting a dozen processes should ensure that this happens.
>
It wasnt so easy to trigger.. but it did.

> This is the same problem that makes "top" report negative %idle.
>
> The kernel's count of idle ticks can briefly run backwards.
> This is because the idle count is derived from other values,
> which are updated without any locking. When vmstat reads the
> idle time during an update, it can go backwards.
>
> This may be intentional; locking would add overhead, and these
> values are not really important.
>
> The negative number causes an unsigned 32-bit integer underflow.
> After some division and rounding, you get the above values.
>
> Do you want to see the values as they arrive (as "-1" or "-2")
> or do you want them converted to "0" to look pretty?
>
IMHO it would be better to report the values as they arrive, and to document
this somewhere... this would make us + sys + id = 100, which is far more
coherent than the other choices (as-is, and 0).
On the other hand, reporting 0 and adding an option to make it show the real
value could avoid some bug reports like mine.
As you stated before, this values aren't so important.

> I forget where you reported this bug. If it wasn't directly to me,
> then please post my response whereever it was you sent the bug report.
I posted it to lkml

Thanks,
Alberto

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.019 / U:4.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site