Re: Weird vmstat reports in 2.2.18

[Alberto Bertogli <albertogli@altavista.net>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]