From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ferenc Wagner <wferi@niif.hu>
Cc: linux-kernel@vger.kernel.org, Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: doubled idle count
Date: Thu, 18 Sep 2008 12:34:54 -0700 [thread overview]
Message-ID: <48D2AD5E.7040602@goop.org> (raw)
In-Reply-To: <87vdwtfxng.fsf@tac.ki.iif.hu>
Ferenc Wagner wrote:
> Hi,
>
> After upgrading a Xen virtual machine to Debian's 2.6.26-4 kernel, I
> noticed that the idle counter doubled its pace on one of the machines:
>
> service2:~# yes >/dev/null &
> [1] 32578
> service2:~# grep cpu0 /proc/stat; sleep 1; grep cpu0 /proc/stat
> cpu0 141208 9113 57273 13379659 61012 0 792 2350 0
> cpu0 141310 9113 57274 13379659 61012 0 792 2350 0
> service2:~# fg
> yes > /dev/null
> ^C
> service2:~# grep cpu0 /proc/stat; sleep 1; grep cpu0 /proc/stat
> cpu0 141952 9113 57277 13383481 61012 0 792 2350 0
> cpu0 141953 9113 57278 13383681 61012 0 792 2350 0
>
Sorry, could you be clearer here? What are we looking at?
> One out of three machines show this effect, with the exact same kernel
> and Xen versions (3.2.0, dom0 is Debian's stock Etch 2.6.18 kernel).
> They aren't hosted by the same machine, though: the misbehaving one is
> on a different installation with very similar hardware (3 vs 2 GHz).
> All the guest are paravirtual.
>
So you're saying that they are identical Xen and guest kernel binaries,
but one of three is showing doubled idle time?
That seems unlikely. The source of that time is from Xen itself, and I
think it should be hardware independent, though I guess its possible
there's something going on at in the Xen-level timekeeping.
That said, I think there's some chance that stolen time may get counted
as idle time. Does the one machine with a different outcome have
something else running in another virtual machine (including dom0)?
J
> service2:~# cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 3.06GHz
> stepping : 5
> cpu MHz : 3056.482
> cache size : 1024 KB
> physical id : 0
> siblings : 1
> core id : 0
> cpu cores : 1
> apicid : 1
> initial apicid : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu de tsc msr pae cx8 cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht pbe up pebs bts cid xtpr
> bogomips : 6128.11
> clflush size : 64
> power management:
>
> I don't know what else would be useful, please ask.
>
next prev parent reply other threads:[~2008-09-18 19:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 12:26 doubled idle count Ferenc Wagner
2008-09-18 19:34 ` Jeremy Fitzhardinge [this message]
2008-09-18 21:24 ` Ferenc Wagner
2008-09-19 13:20 ` Ferenc Wagner
2008-09-21 12:05 ` Ferenc Wagner
2008-09-21 12:27 ` Ferenc Wagner
2008-11-07 15:20 ` Ferenc Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D2AD5E.7040602@goop.org \
--to=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wferi@niif.hu \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox