[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220415133356.179706384@linutronix.de>
Date: Fri, 15 Apr 2022 21:19:48 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: x86@...nel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
linux-pm@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: [patch 00/10] x86/cpu: Consolidate APERF/MPERF code
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.
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