[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220419215656.GT4285@paulmck-ThinkPad-P17-Gen-1>
Date: Tue, 19 Apr 2022 14:56:56 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
"Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [patch 00/10] x86/cpu: Consolidate APERF/MPERF code
On Fri, Apr 15, 2022 at 09:19:48PM +0200, Thomas Gleixner wrote:
> APERF/MPERF is utilized in two ways:
>
> 1) Ad hoc readout of CPU frequency which requires IPIs
>
> 2) Frequency scale calculation for frequency invariant scheduling which
> reads APERF/MPERF on every tick.
>
> These are completely independent code parts. Eric observed long latencies
> when reading /proc/cpuinfo which reads out CPU frequency via #1 and
> proposed to replace the per CPU single IPI with a broadcast IPI.
>
> While this makes the latency smaller, it is not necessary at all because #2
> samples APERF/MPERF periodically, except on idle or isolated NOHZ full CPUs
> which are excluded from IPI already.
>
> It could be argued that not all APERF/MPERF capable systems have the
> required BIOS information to enable frequency invariance support, but in
> practice most of them do. So the APERF/MPERF sampling can be made
> unconditional and just the frequency scale calculation for the scheduler
> excluded.
>
> The following series consolidates that.
Acked-by: Paul E. McKenney <paulmck@...nel.org>
> Thanks,
>
> tglx
> ---
> arch/x86/include/asm/cpu.h | 2
> arch/x86/include/asm/topology.h | 17 -
> arch/x86/kernel/acpi/cppc.c | 28 --
> arch/x86/kernel/cpu/aperfmperf.c | 474 +++++++++++++++++++++++++++++++--------
> arch/x86/kernel/cpu/proc.c | 2
> arch/x86/kernel/smpboot.c | 358 -----------------------------
> fs/proc/cpuinfo.c | 6
> include/linux/cpufreq.h | 1
> 8 files changed, 405 insertions(+), 483 deletions(-)
>
>
Powered by blists - more mailing lists