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

[Jing Wu <realwujing@gmail.com>]

On Wed, Jul 29, 2026 at 08:39:12PM +0800, Peter Zijlstra wrote:
> 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'.

Yes, sorry for the confusion - it's the sysfs files. To be concrete
about why: when someone is chasing a real incident (packet latency in
an OVS/DPDK PMD pipeline pinned to one of these cores, say), reading
scaling_cur_freq/cpuinfo is one of the first things they check. Seeing
the P-state floor while the core is genuinely at full turbo sends that
investigation down the wrong path and burns real engineering time.

-EOPNOTSUPP doesn't fix that particular problem: the operator still
gets nothing useful from the standard interface and has to fall back
to turbostat regardless, so the diagnostic workflow ends up no better
off than it is today.

Given that, I'd like to make the case for going back to something
closer to the original approach: it's a small, self-contained change,
and it reports the actual value instead of an estimate or nothing.
The concern was IPIs turning periodic if something scrapes this file
on a schedule - but for the isolated cores we run PMD workloads on,
nothing polls per-core scaling_cur_freq/cpuinfo on any kind of
schedule; it only gets read by a person during an investigation, which
is a rare, deliberate action, not unlike running turbostat by hand.

Would you reconsider on that basis, or is there a middle ground you'd
be open to?