Weird vmstat reports in 2.2.18

Weird vmstat reports in 2.2.18

[albertogli]

I'm getting some strange reports with vmstat on a dual iPPro running 2.2.18,
it doesnt happen very frequently, but i see it a lot when compiling something 
(kernel and mysql specially, not when compiling small stuff), though it doesnt 
look like a high-load issue. When the machine is idle (ie. most of the time at 
the moment) it doesnt show up.

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...
BUT if i open two vmstats in different consoles.. the number doesnt show up in 
both, just in one of them... so i'm not sure at all if this is a kernel bug, or 
just another (vmstat?) feature =)
I also found a reference to something similar in 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.3/0273.html

       Alberto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Weird vmstat reports in 2.2.18

[john slee]

On Wed, Dec 20, 2000 at 11:55:37AM -0300, albertogli@telpin.com.ar wrote:
> I'm getting some strange reports with vmstat on a dual iPPro running 2.2.18,
> it doesnt happen very frequently, but i see it a lot when compiling something
> (kernel and mysql specially, not when compiling small stuff), though it doesnt
> look like a high-load issue. When the machine is idle (ie. most of the time at
> the moment) it doesnt show up.

i can consistently produce this on dual p3 600/2.2.17pre20.  in my case
it's the `ab' benchmark tool supplied with apache that helps reproduce
it.  incidentally i only noticed this in the last day or two, good to
know i'm not the only one. :-)

our setup is apache/php/postgresql.  fairly intensive pages.  i start
seeing vmstat oddities after about 15 concurrent requests.

> I wasnt able to trigger it in a predictable way, it just pops up...
> BUT if i open two vmstats in different consoles.. the number doesnt show up in
> both, just in one of them... so i'm not sure at all if this is a kernel bug, or
> just another (vmstat?) feature =)

the vmstat processes probably aren't reading /proc/* at exactly the same
time, so the numbers they see will likely be different... 

j.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Weird vmstat reports in 2.2.18

[Alberto Bertogli]

[-- 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 --]