Re: [PATCH v2 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64

Hi,

On 7/8/26 3:28 AM, Pengjie Zhang wrote:
> The legacy CPPC feedback-counter path reads the delivered and reference
> performance counters separately.
> 
> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
> served through a cross-CPU counter read helper. Reading the counters
> separately therefore widens the sampling window between them and can
> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
> load, the skew is observable as transient values that may exceed the
> platform maximum, as discussed in [1] and [2].
> 
> This series adds a small generic hook for architectures that can obtain
> both FFH feedback counters in one operation, while preserving the
> existing per-register read path as the fallback.
> 
> Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
> Patch 2 implements the hook on arm64 by sampling both AMU counters in a
> single operation on the target CPU.
> 
> For detailed test results and data demonstrating the observable skew and
> the improvements brought by this series, please refer to [3] and [4].

So, this set appears to help considerably, I have a small script which 
after setting a fixed CPU frequency proceeds to sample cpuinfo_cur_freq 
and builds the mean/stddev/stderr and worst case error percentage. Its 
really the latter that I've been focusing on. When run under varying 
workloads, local vs cross cpu, t builds what I think is a somewhat 
reasonable picture of the machine behaviors.

Given a machine that at a baseline, has an error percentage that can 
exceed 100% (ex the actual frequency is 2.4Ghz, and it can report > 
5Ghz), this patch appears to bring the worst case down to approximately 
~20%, but usually its somewhere around 5%. This is similar to the v1 of 
the jitter patch I posted, but worse than than the best sample version 
of the jitter patch I've been promising, which does a better job 
selecting the initial sample.

But combining them is magic, the tweaked version reduces that to less 
than a percent.

The combination appears good enough to consistently detect small 
variations between the requested frequencies and the rate the delivered 
clock is claiming (ex request 2600 Mhz, consistently get 2630 Mhz +- 2Mhz).


With that:

Tested-by: Jeremy Linton <[email protected]>

I have a small nitpik for review, that should only be considered if for 
some reason this gets respun, but otherwise.

Reviewed-by: Jeremy Linton <[email protected]>




> 
> [1] https://lore.kernel.org/all/[email protected]/
> [2] https://lore.kernel.org/all/[email protected]/
> [3] https://lore.kernel.org/all/[email protected]/
> [4] https://lore.kernel.org/all/[email protected]/
> 
> Tested-by: Sumit Gupta <[email protected]>
> Reviewed-by: Sumit Gupta <[email protected]>
> Tested-by: Vanshidhar Konda <[email protected]>
> Reviewed-by: Vanshidhar Konda <[email protected]>
> Signed-off-by: Pengjie Zhang <[email protected]>
> ---
> Changes in v2:
> - Simplified the CPPC generic layer fallback logic to prevent pointless single-read retries.
> - Added upfront register validation in the arm64 hook to avoid unnecessary IPI overhead.
> - Explicitly flipped the -EOPNOTSUPP error to -ENODEV in the arm64 hook when AMU is unsupported, cleanly bypassing redundant CPPC generic fallbacks.
> - Addressed other kernel-doc and naming feedbacks from Beata.
> - Added Reviewed-by and Tested-by tags from Vanshidhar and Sumit
> - Link to v1: https://lore.kernel.org/all/[email protected]/
> 
> Pengjie Zhang (2):
>    ACPI: CPPC: add paired FFH feedback-counter read hook
>    arm64: topology: read CPPC FFH feedback counters in one operation
> 
>   arch/arm64/kernel/topology.c | 92 ++++++++++++++++++++++++++++++++----
>   drivers/acpi/cppc_acpi.c     | 50 ++++++++++++++++++--
>   include/acpi/cppc_acpi.h     |  7 +++
>   3 files changed, 136 insertions(+), 13 deletions(-)
>