linux-kernel - Re: [REGRESSION] High, likely incorrect process cpu usage counters with kvm and 2.6.2[67]

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f7848160808311109v70db1e99hb6af3b89c34d0d8c@mail.gmail.com>
Date:	Sun, 31 Aug 2008 14:09:51 -0400
From:	"Parag Warudkar" <parag.lkml@...il.com>
To:	"Avi Kivity" <avi@...ranet.com>
Cc:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Ingo Molnar" <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"KVM list" <kvm@...r.kernel.org>
Subject: Re: [REGRESSION] High, likely incorrect process cpu usage counters with kvm and 2.6.2[67]

On Sun, Aug 31, 2008 at 11:43 AM, Avi Kivity <avi@...ranet.com> wrote:
> 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.

Busted process accounting - This looks the same as
http://bugzilla.kernel.org/show_bug.cgi?id=11209 .
Please verify. Peter's patch in latest git stops showing "incorrect
looking" CPU usage but at least the process times are still wrong,
horribly.
In fact the CPU usage thing in -rc5 is likely also incorrect but I
need to analyze that bit a little more.

>From Today's Git -

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

12961 parag     20   0 83000 8908 6628 R    0  0.1  5124415h npviewer.bin

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

That patch sounds like it had open questions?
Really giving this is a long standing bad regression, all the
offending patches should be reverted in absence of a fix, no?

Parag
--
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/