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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Jul 28, 2026 at 07:27:54PM +0800, Jing Wu wrote:
> An isolated CPU covered by nohz_full stops its periodic tick once it
> has only one runnable task, since sched_can_stop_tick() only checks
> scheduling-class fairness and has no notion of cpufreq reporting
> needs. arch_scale_freq_tick() runs only from scheduler_tick(), so
> cpu_samples for that CPU is never refreshed again.
> 
> arch_freq_get_on_cpu() then permanently hits its staleness check and
> falls back to cpufreq_quick_get(), which returns whatever policy->cur
> was left at (typically the P-state floor). This happens even though
> HWP hardware keeps running the CPU at full turbo autonomously, as
> confirmed by turbostat and by directly reading APERF/MPERF.
> 
> Reproduce on an isolated, nohz_full CPU with intel_pstate/HWP by
> loading it and watching scaling_cur_freq stay pinned at the floor:
> 
>     taskset -c $CPU stress --cpu 1 &
>     for i in $(seq 10); do
>         cat /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_cur_freq
>         sleep 0.5
>     done
>     turbostat --cpu $CPU --interval 1 --num_iterations 5
> 
> scaling_cur_freq stays at the floor for the whole run, while
> turbostat's Bzy_MHz confirms the CPU is actually at full turbo.
> 
> Refresh the stale sample with one on-demand arch_scale_freq_tick()
> via IPI before falling back, but only when the target CPU is online
> and not idle. APERF/MPERF both stop advancing during idle (C1+), so
> a delta computed over an arbitrarily long stale window still yields
> a correct busy-time frequency average.

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.