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

[Vanshidhar Konda]

On Wed, May 20, 2026 at 10:55:54AM +0800, Pengjie Zhang wrote:
>
>On 5/19/2026 6:47 PM, Will Deacon wrote:
>>On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
>>>Hi all,
>>>
>>>Gentle ping on this thread. It has been a while since I posted it.
>>>
>>>Could someone please take a look when you have time? If there is anything
>>>I should revise or any additional information needed, I'd be happy to
>>>update it.
>>It's hard to find active folks who have contributed meaningfully to the
>>cppc_acpi driver... I've added Ionella and Jeremy, in case they can take
>>a look.
>>
>>Will
>Thanks Will, and thanks for adding Ionela and Jeremy.
>
>While waiting for further comments, I would like to add some
>test data to make the effect of this series clearer.
>
>On the test platform, the maximum frequency reported by the platform
>is 2300000. I sampled cpuinfo_cur_freq before and after applying this 
>series.
>
>Before applying the series, the samples showed visible transient outliers.
>??The minimum value was 2154583 and the maximum value was 2491071.
>There were 8 samples above 2400000 and 8 samples below 2200000.
>The largest value exceeded the platform maximum by about 8.3%.
>
>After applying the series, the samples became much more stable.
>The minimum value was 2290243 and the maximum value was 2306310.
>There were no samples above 2400000 and no samples below 2200000.
>The largest value exceeded the platform maximum by only about 0.27%.
>
>A summary of the 96 samples is:
>
>?? ?? ?? ?? ?? ?? ?? ?? ?? ?? before?? ?? ?? ?? ?? after
>min?? ?? ?? ?? ?? ?? ?? 2154583?? ?? ?? ?? ??2290243
>max?? ?? ?? ?? ?? ?? ?? 2491071?? ?? ?? ?? ??2306310
>range?? ?? ?? ?? ?? ?? ??336488?? ?? ?? ?? ?? ??16067
>average?? ?? ?? ?? ?? 2298436.4?? ?? ?? ??2298479.4
>stddev?? ?? ?? ?? ?? ?? ??55184.1?? ?? ?? ?? ?? 2868.2
>samples > 2300000?? 26 / 96?? ?? ?? ?? ??16 / 96
>samples > 2400000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>samples < 2200000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>
>So this series does not try to clamp the value to the platform maximum.
>??Instead, it reduces the sampling skew between the delivered and reference
>feedback counters. The remaining small deviation around 2300000 is
>??much smaller than the previous transient spikes.
>
>One concern that may come up is that an FFH read may cause an idle
>target CPU to be woken, depending on the platform/vendor implementation.
>However, that behavior is not introduced by this series. It is already part
>of how FFH counter reads are implemented on such platforms. This series
>only changes the sampling form for the FFH feedback counters: when both
>delivered and reference counters are FFH counters, read them together
>instead of issuing two separate FFH reads.
>
>If the target CPU has to be involved for an FFH read, doing one paired
>read should be no worse than doing two separate reads, and it also
>narrows the sampling window between the two counters.
>

I agree with this point. It reduces the number of times the idle CPU
is woken up just to read counters.

>If there is any concern about the generic hook or the arm64 implementation,
>I would be happy to revise it.
>
>The raw data is as follows:
>before:
>2303809 2294827 2300000 2293643 2290740 2300000 2297228 2296082
>2301707 2295354 2296601 2303163 2296766 2296543 2295412 2298394
>2297387 2300000 2308274 2301882 2297752 2418568 2491071 2300000
>2183264 2296238 2434731 2296721 2439777 2302159 2301773 2298226
>2300000 2305936 2301133 2297511 2300000 2300000 2294408 2298494
>2295011 2302721 2295955 2301505 2298064 2297419 2298933 2189595
>2298058 2296046 2300000 2301449 2414908 2296559 2305251 2166666
>2296626 2173303 2300000 2298806 2411389 2301822 2297291 2300000
>2423831 2297902 2300000 2435730 2302433 2295353 2298898 2296043
>2321868 2294907 2300000 2157841 2296052 2206530 2300000 2297811
>2297920 2294382 2297767 2157230 2302564 2298504 2296822 2300000
>2296868 2294866 2154583 2290888 2302542 2292549 2300000 2184259
>
>after:
>2303738 2296153 2298087 2295607 2301373 2298076 2300000 2295081
>2297788 2300000 2300000 2295238 2301449 2300000 2298488 2297911
>2301477 2298507 2294976 2296852 2293689 2294077 2293887 2292619
>2300000 2300000 2298072 2300000 2291943 2300000 2295370 2300000
>2301873 2304645 2300000 2296766 2300000 2300000 2290243 2297954
>2297183 2306310 2300000 2296889 2300000 2303800 2301970 2296888
>2300000 2301354 2300000 2298405 2298202 2296767 2298663 2302522
>2297821 2302471 2300000 2303233 2298226 2298698 2300000 2297291
>2296470 2300000 2298398 2300000 2295681 2300000 2300000 2296344
>2300000 2296008 2302375 2297977 2298447 2296519 2295565 2294866
>2297945 2300000 2294978 2303595 2300000 2300000 2294930 2301096
>2296271 2296086 2294482 2300000 2294843 2300000 2296803 2295708

I tested this series on Ampere AmpereOne A192-32X.

Tested-by: Vanshidhar Konda <vanshikonda at os.amperecomputing.com>
Reviewed-by: Vanshidhar Konda <vanshikonda at os.amperecomputing.com>

Regards,
Vanshidhar Konda

>>>On 4/10/2026 5:41 PM, 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.
>>>>
>>>>[1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
>>>>[2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>>>
>>>>Signed-off-by: Pengjie Zhang <zhangpengjie2 at huawei.com>
>>>>
>>>>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 | 75 ++++++++++++++++++++++++++++++++----
>>>>   drivers/acpi/cppc_acpi.c     | 58 +++++++++++++++++++++++++---
>>>>   include/acpi/cppc_acpi.h     |  7 ++++
>>>>   3 files changed, 127 insertions(+), 13 deletions(-)
>>>>