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

[Jing Wu <realwujing@gmail.com>]

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.

Thanks,
Jing Wu