[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1711150943030.1805@nanos>
Date: Wed, 15 Nov 2017 09:47:11 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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, 14 Nov 2017, Linus Torvalds wrote:
> 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.
>
Tired brain did not connect it to the revert.
On that machine with ea0ee3398877: Revert "x86: CPU: Fix up "cpu MHz" in
/proc/cpuinfo" reverted it takes:
real 0m4.497s
user 0m0.012s
sys 0m0.000s
> It sounds like the current patch is slower, but likely acceptable
> considering that you get the right results now ..
Correct and the factor 10, i.e. 30ms vs. 3ms is not horrible, while the 4.5
seconds are.
Thanks,
tglx
Powered by blists - more mailing lists