[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFw=JkvmxohBtVy-3QPtFibq_rv_uqp3ss+gpo8vSqYGQw@mail.gmail.com>
Date: Tue, 14 Nov 2017 16:04:32 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
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 Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> Current head + Raphaels patch:
>
> real 0m0.029s
> user 0m0.000s
> sys 0m0.010s
>
> So that patch is actually slower.
Oh it definitely is expected to be slower, because it does the IPI to
all the cores and actually gets their frequency right.
It was the old one that we had to revert (because it did so
sequentially) that was really bad, and took something like 2+ seconds
on Ingo's 160-core thing, iirc.
It sounds like the current patch is slower, but likely acceptable
considering that you get the right results now ..
Linus
Powered by blists - more mailing lists