Users may have noticed unusually high cpu usage when running kvm on recent kernels ie. 2.6.26 and 2.6.27. There’s currently some discussion on the kvm development mailing list that this is likely due to incorrect reporting because of a bug in the recent kernels. Avi Kivity, lead maintainer of the KVM project observed:

Running an idle Windows VM on Linux 2.6.26+ with kvm, one sees high values for the kvm process in top (30%-70% cpu), where one would normally expect 0%-1%. Surprisingly, the per-cpu system counters show almost 100% idle, leading me to believe this is an accounting error and that the process does not actually consume this much cpu.

I bisected this to a scheduler change, namely

commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
Author: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Sat May 3 18:29:28 2008 +0200

sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
this replaces the rq->clock stuff (and possibly cpu_clock()). - architectures that have an 'imperfect' hardware clock can set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
- the 'jiffie' window might be superfulous when we update tick_gtod
before the __update_sched_clock() call in sched_clock_tick()
- cpu_clock() might be implemented as: sched_clock_cpu(smp_processor_id()) if the accuracy proves good enough - how far can TSC drift in a
single jiffie when considering the filtering and idle hooks?
[ [EMAIL PROTECTED]: various fixes and cleanups ] Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

Which is a bit too complex for me to work out.

Further information:
- the kvm thread which has the incorrect counter is the one that actually executes guest code
- this thread mostly sleeps in schedule(), as one would expect
- it is periodically woken up by a timer; perhaps the problem is that the process is sampled using the same timer, so it always shows as running (though I'd expect it to report 100% cpu in that case).

Any help will be appreciated (or provided).

You can follow the discussion on the mailing list archives at the following link.

http://www.mail-archive.com/kvm@vger.kernel.org/msg03280.html