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

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

[Pengjie Zhang]

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@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(-)

-- 
2.33.0

[PATCH 1/2] ACPI: CPPC: add paired FFH feedback-counter read hook

[Pengjie Zhang]

cppc_get_perf_ctrs() reads the delivered and reference performance
counters one at a time.

Allow architectures to provide both FFH feedback counters in one
operation when that either narrows the sampling window or avoids extra
cross-CPU reads. Add a small FFH-specific hook for that case and fall
back to the existing per-register reads when unsupported.

Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
---
 drivers/acpi/cppc_acpi.c | 58 ++++++++++++++++++++++++++++++++++++----
 include/acpi/cppc_acpi.h |  7 +++++
 2 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 2e91c5a97761..7b3e8b0597dc 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -988,6 +988,23 @@ int __weak cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
 	return -ENOTSUPP;
 }
 
+/**
+ * cpc_read_ffh_fb_ctrs() - Read FFH feedback counters together
+ * @cpunum:	CPU number to read
+ * @reg1:	first CPPC register information
+ * @val1:	place holder for first return value
+ * @reg2:	second CPPC register information
+ * @val2:	place holder for second return value
+ *
+ * Return: 0 for success and error code
+ */
+int __weak cpc_read_ffh_fb_ctrs(int cpunum, struct cpc_reg *reg1,
+				u64 *val1, struct cpc_reg *reg2, u64 *val2)
+{
+	return -EOPNOTSUPP;
+}
+
+
 /**
  * cpc_write_ffh() - Write FFH register
  * @cpunum:	CPU number to write
@@ -1504,6 +1521,40 @@ bool cppc_perf_ctrs_in_pcc(void)
 }
 EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
 
+static int cppc_read_perf_fb_ctrs(int cpunum,
+				  struct cpc_register_resource *delivered_reg,
+				  struct cpc_register_resource *reference_reg,
+				  u64 *delivered, u64 *reference)
+{
+	int ret;
+
+	/*
+	 * For FFH feedback counters, try a paired read first to reduce
+	 * sampling skew between delivered and reference counters. Fall
+	 * back to the existing per-register reads if unsupported.
+	 */
+	if (CPC_IN_FFH(delivered_reg) && CPC_IN_FFH(reference_reg)) {
+		ret = cpc_read_ffh_fb_ctrs(cpunum,
+					&delivered_reg->cpc_entry.reg, delivered,
+					&reference_reg->cpc_entry.reg, reference);
+		if (!ret)
+			return 0;
+
+		if (ret != -EOPNOTSUPP)
+			return ret;
+	}
+
+	ret = cpc_read(cpunum, delivered_reg, delivered);
+	if (ret)
+		return ret;
+
+	ret = cpc_read(cpunum, reference_reg, reference);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 /**
  * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
  * @cpunum: CPU from which to read counters.
@@ -1547,11 +1598,8 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
 		}
 	}
 
-	ret = cpc_read(cpunum, delivered_reg, &delivered);
-	if (ret)
-		goto out_err;
-
-	ret = cpc_read(cpunum, reference_reg, &reference);
+	ret = cppc_read_perf_fb_ctrs(cpunum, delivered_reg, reference_reg,
+				     &delivered, &reference);
 	if (ret)
 		goto out_err;
 
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index d1f02ceec4f9..006b42dbbd4b 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -172,6 +172,8 @@ extern int cppc_get_transition_latency(int cpu);
 extern bool cpc_ffh_supported(void);
 extern bool cpc_supported_by_cpu(void);
 extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
+extern int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
+				struct cpc_reg *reg2, u64 *val2);
 extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
 extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
 extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
@@ -246,6 +248,11 @@ static inline int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
 {
 	return -EOPNOTSUPP;
 }
+static inline int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
+				       struct cpc_reg *reg2, u64 *val2)
+{
+	return -EOPNOTSUPP;
+}
 static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
 {
 	return -EOPNOTSUPP;
-- 
2.33.0

[PATCH 2/2] arm64: topology: read CPPC FFH feedback counters in one operation

[Pengjie Zhang]

arm64 implements CPPC FFH feedback-counter reads using AMU counters.
Because those counters must be sampled on the target CPU, reading the
delivered and reference counters separately widens the observation window
between them.

Implement the paired FFH feedback-counter read hook on arm64 and sample
both AMU counters together before decoding the requested CPC register
values.

Also factor the FFH bitfield extraction logic into a helper and reuse
it from the existing single-counter FFH read path.

Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
---
 arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
 1 file changed, 67 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index b32f13358fbb..b90a767b2a1f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -50,6 +50,16 @@ struct amu_cntr_sample {
 	unsigned long	last_scale_update;
 };
 
+struct amu_ffh_ctrs {
+	u64 corecnt;
+	u64 constcnt;
+};
+
+enum cpc_ffh_ctr_id {
+	CPC_FFH_CTR_CORE  = 0x0,
+	CPC_FFH_CTR_CONST = 0x1,
+};
+
 static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample, cpu_amu_samples);
 
 void update_freq_counters_refs(void)
@@ -397,7 +407,7 @@ static void cpu_read_constcnt(void *val)
 }
 
 static inline
-int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
+int counters_read_on_cpu(int cpu, smp_call_func_t func, void *val)
 {
 	/*
 	 * Abort call on counterless CPU.
@@ -447,24 +457,73 @@ bool cpc_ffh_supported(void)
 	return true;
 }
 
+static void amu_read_core_const_ctrs(void *val)
+{
+	struct amu_ffh_ctrs *ctrs = val;
+
+	cpu_read_constcnt(&ctrs->constcnt);
+	cpu_read_corecnt(&ctrs->corecnt);
+}
+
+static u64 cpc_ffh_extract_bits(const struct cpc_reg *reg, u64 val)
+{
+	val &= GENMASK_ULL(reg->bit_offset + reg->bit_width - 1,
+			   reg->bit_offset);
+	val >>= reg->bit_offset;
+
+	return val;
+}
+
+static bool cpc_ffh_ctr_value(const struct cpc_reg *reg,
+			      const struct amu_ffh_ctrs *ctrs, u64 *val)
+{
+	switch ((u64)reg->address) {
+	case CPC_FFH_CTR_CORE:
+		*val = ctrs->corecnt;
+		break;
+	case CPC_FFH_CTR_CONST:
+		*val = ctrs->constcnt;
+		break;
+	default:
+		return false;
+	}
+
+	*val = cpc_ffh_extract_bits(reg, *val);
+	return true;
+}
+
+int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
+			 struct cpc_reg *reg2, u64 *val2)
+{
+	struct amu_ffh_ctrs ctrs;
+	int ret;
+
+	ret = counters_read_on_cpu(cpu, amu_read_core_const_ctrs, &ctrs);
+	if (ret)
+		return ret;
+
+	if (!cpc_ffh_ctr_value(reg1, &ctrs, val1) ||
+	    !cpc_ffh_ctr_value(reg2, &ctrs, val2))
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
 int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
 {
 	int ret = -EOPNOTSUPP;
 
 	switch ((u64)reg->address) {
-	case 0x0:
+	case CPC_FFH_CTR_CORE:
 		ret = counters_read_on_cpu(cpu, cpu_read_corecnt, val);
 		break;
-	case 0x1:
+	case CPC_FFH_CTR_CONST:
 		ret = counters_read_on_cpu(cpu, cpu_read_constcnt, val);
 		break;
 	}
 
-	if (!ret) {
-		*val &= GENMASK_ULL(reg->bit_offset + reg->bit_width - 1,
-				    reg->bit_offset);
-		*val >>= reg->bit_offset;
-	}
+	if (!ret)
+		*val = cpc_ffh_extract_bits(reg, *val);
 
 	return ret;
 }
-- 
2.33.0

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

[zhangpengjie (A)]

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.

Thanks!

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@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(-)
>

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

[Will Deacon]

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

> 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@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(-)
> > 

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

[Pengjie Zhang]

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.

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
>> 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@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(-)
>>>

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

[Beata Michalska]

Apologies but this one completely skipped my radar.
Will have a look in the next few days.

---
BR
Beata
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.
> 
> 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
> > > 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@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(-)
> > > >