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
PGP signature
