Messages in this thread |  | | Date | Sun, 14 Jan 2001 12:23:15 -0300 | From | Alberto Bertogli <> | Subject | Re: 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] |  |