Re: [PATCH] x86/aperfmperf: Refresh stale sample via IPI for busy NOHZ_FULL CPUs

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Jul 29, 2026 at 04:22:24PM +0800, Jing Wu wrote:
> On Tue, Jul 28, 2026 at 04:42:24PM +0200, Peter Zijlstra wrote:
> > Aside from the fact that sending IPIs to NOHZ_FULL is just plain wrong,
> > this whole thing makes no sense.
> >
> > When the CPU is isolated, nothing should care about the ratio anyway.
> > Just set the thing to '1' (1024) when the CPU enters NOHZ_FULL mode and
> > ensure it isn't ever modified.
> 
> Fair, understood.
> 
> For context on why I went looking in the first place: stressing an
> isolated, nohz_full CPU shows both /proc/cpuinfo's "cpu MHz" and
> /sys/devices/system/cpu/cpuN/cpufreq/scaling_cur_freq stuck at the
> P-state floor (e.g. 800MHz) for as long as the CPU stays busy and
> isolated, while turbostat confirms the hardware is actually running
> at full turbo (e.g. 3.2GHz) the whole time. Both interfaces go
> through arch_freq_get_on_cpu(), so whatever affects one affects both.
> 
> Getting the exact value would need an on-demand rdmsr on the target
> CPU - which is what turbostat itself does via /dev/cpu/N/msr's
> rdmsr_safe_regs_on_cpu(), i.e. the same smp_call_function_single()
> IPI, just triggered manually by a human running a diagnostic tool
> instead of sitting behind a commonly-polled sysfs file.
> 
> I looked for a way around that: PCU mailbox telemetry can expose a
> per-core P-state on some Xeon uncores without touching the target
> CPU, and HFI publishes a shared table too, but that's a per-core
> performance/efficiency class, not an achieved clock, and PCU access
> is uncore/generation-specific, not a general mechanism. So as far as
> I can tell there's no way to get the exact value for an isolated CPU
> without an IPI of some form.

Oh, you care about the silly sysfs files? I though this was about the
scheduler use of aperf/mperf ratio.

Both are driven from the same source, but the scheduler use makes no
sense when isolated/NOHZ_FULL. And I would argue that keeping the CPU
isolated is more important than having the silly number 'accurate'.

Something like so perhaps?

diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index 7ffc78d5ebf2..cedb40e6b5e6 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -438,7 +438,8 @@ static void scale_freq_tick(u64 acnt, u64 mcnt)
 {
 	u64 freq_scale, freq_ratio;
 
-	if (!arch_scale_freq_invariant())
+	if (!arch_scale_freq_invariant() ||
+	    !housekeeping_cpu(smp_processor_id(), HK_TYPE_TICK))
 		return;
 
 	if (check_shl_overflow(acnt, 2*SCHED_CAPACITY_SHIFT, &acnt))
@@ -510,6 +511,9 @@ int arch_freq_get_on_cpu(int cpu)
 	unsigned long last;
 	u64 acnt, mcnt;
 
+	if (!housekeeping_cpu(cpu, HK_TYPE_TICK))
+		return -EOPNOTSUPP;
+
 	if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF))
 		goto fallback;