lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 31 Aug 2008 18:43:21 +0300 From: Avi Kivity <avi@...ranet.com> To: Peter Zijlstra <a.p.zijlstra@...llo.nl>, Ingo Molnar <mingo@...e.hu> CC: linux-kernel <linux-kernel@...r.kernel.org>, KVM list <kvm@...r.kernel.org> Subject: [REGRESSION] High, likely incorrect process cpu usage counters with kvm and 2.6.2[67] 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 <a.p.zijlstra@...llo.nl> 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? [ mingo@...e.hu: various fixes and cleanups ] Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl> Signed-off-by: Ingo Molnar <mingo@...e.hu> 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). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists