Re: [PATCH] cpu idle ticks show twice in xen pvm guest

[Ferenc Wagner <wferi@niif.hu>]

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

Jeremy Fitzhardinge <jeremy@goop.org> writes:

>> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
>>
>>> Run below test on xen pvm.
>>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
>>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
>>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
>>>
>>> @ X:58562301
>>> @ Y:58574282
>>> @ IDLE: 199.600
>>>
>>> Normal idle percent should be around 100%.
>>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
>>> but these ticks will be accounted again when idle ticks restarted.
>>>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
>
> Does this affect the accounting of stolen ticks?  If it does, that's not
> necessarily a showstopper for this patch, but we'll need to do some more
> thinking about it.  Certainly, accurate accounting for idleness is
> important.

Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
I found that the counter doubling isn't always present under 2.6.26.
However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
April on the graph below) that instability seems to disappear.  Please
note that the following graph shows halved idle and iowait percentages.


[-- Attachment #2: Modified Munin graph --]
[-- Type: image/png, Size: 17739 bytes --]

[-- Attachment #3: Type: text/plain, Size: 708 bytes --]


(I haven't collected steal values, so the numbers don't sum up to 100%.)
I'd be grateful if this discrepancy could be cleared up eventually!
It's heartening to see some progress after more than three years. :)

Actually, as Munin doesn't half the idle and iowait values, but
truncates the (then overflowing) graph at 100%, I was rather surprised
to see iowait completely disappear after the kernel upgrade, and
concluded that it was somehow converted into buggy-looping in blkfront.
Now I see this isn't the case, but the steadily increasing system CPU
usage between reboots is still a mystery.  I'll start a separate thread
for that, just wanted to provide some motivation for this topic.
--
Thanks,
Feri.