linux-kernel - Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

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: <1640278.1Q7Qv8A4h4@aspire.rjw.lan>
Date:   Wed, 15 Nov 2017 01:06:37 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        WANG Chao <chao.wang@...oud.cn>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Len Brown <len.brown@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Mathias Krause <minipli@...glemail.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On Wednesday, November 15, 2017 12:53:24 AM CET Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Linus Torvalds wrote:
> 
> > On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> > >
> > > So what about the one below?  It works for me as expected.
> > 
> > Can somebody with 100+ cores test this? Ingo? You had a 160 core
> > machine that took forever, didn't you..
> 
> On a 144 CPUs machine:
> 
> time cat /proc/cpuinfo >/dev/null
> 
> Current head:
> 
> real	0m0.003s
> user	0m0.000s
> sys	0m0.002s
> 
> Current head + Raphaels patch:
> 
> real	0m0.029s
> user	0m0.000s
> sys	0m0.010s
> 
> So that patch is actually slower.

Thanks for testing!

It is adding a delay (mostly because it has to allow APERF and MPERF to grow
somewhat for the frequency computation to produce a useful result), so it will
be slower even in theory, but really the question is whether or not the slow
down is acceptable.

It doesn't look horrible to me, but that's my patch after all. :-)