linux-kernel - Re: [patch] dynticks core: Fix idle time accounting

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]

Date:	Tue, 03 Oct 2006 22:33:46 -0400
From:	Valdis.Kletnieks@...edu
To:	tglx@...utronix.de
Cc:	Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Jim Gettys <jg@...top.org>,
	John Stultz <johnstul@...ibm.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: [patch] dynticks core: Fix idle time accounting

On Tue, 03 Oct 2006 22:02:30 +0200, Thomas Gleixner said:

> I found a way to fix my thinkos. I put up a queue with all fixes to:
> 
> http://www.tglx.de/projects/hrtimers/2.6.18-mm3/patch-2.6.18-mm3-hrt-dyntick1.patches.tar.bz2
> 
> Can you please verify if it makes your problem go away ?

Was -dyntick3 by the time I got there.

The user/system/idle/wait numbers now look sane, with one caveat:

static const ktime_t nsec_per_hz = { .tv64 = NSEC_PER_SEC / HZ };
...
                if (unlikely(delta.tv64 >= nsec_per_hz.tv64)) {
                        s64 incr = ktime_to_ns(nsec_per_hz);
                        ticks = ktime_divns(delta, incr);

Even though I have CONFIG_HZ=1000, this ends up generating a synthetic
count that works out to 100 per second.  gkrellm and vmstat are happy with
that state of affairs, but I'm not sure why it came out to 100/sec rather
than 1000/sec.

% cat /proc/stat /proc/uptime
cpu  28224 4688 9159 168290 9143 283 256 0
cpu0 28224 4688 9159 168290 9143 283 256 0
intr 818891 627337 3466 0 4 4 6459 3 7 1 1 4 160328 115 0 21162 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 971441
btime 1159926408
processes 4544
procs_running 1
procs_blocked 0
nohz total I:367986 S:302473 T:1737.640072 A:0.005744 E: 625327
2176.02 1775.11

Also, it still disagrees with speedstep - it isn't noticing the TSC has
gone slow and drop back to the PM timer.

All in all, we're making progress. ;)

Content of type "application/pgp-signature" skipped