From: Jeremy Linton <jeremy.linton@arm.com>
To: Pengjie Zhang <zhangpengjie2@huawei.com>,
catalin.marinas@arm.com, will@kernel.org, rafael@kernel.org,
lenb@kernel.org, saket.dumbre@intel.com, beata.michalska@arm.com,
zhenglifeng1@huawei.com, sumitg@nvidia.com,
zhanjie9@hisilicon.com, geert+renesas@glider.be,
cuiyunhui@bytedance.com, vanshikonda@os.amperecomputing.com,
ionela.voinescu@arm.com, viresh.kumar@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
acpica-devel@lists.linux.dev, linuxarm@huawei.com
Cc: prime.zeng@hisilicon.com, wanghuiqiang@huawei.com,
xuwei5@huawei.com, lihuisong@huawei.com, yubowen8@huawei.com,
wangzhi12@huawei.com
Subject: Re: [PATCH v2 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
Date: Thu, 9 Jul 2026 01:07:43 -0500 [thread overview]
Message-ID: <29947b61-d2f3-4161-ac65-197cfe00a99d@arm.com> (raw)
In-Reply-To: <20260708082818.808041-1-zhangpengjie2@huawei.com>
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 <jeremy.linton@arm.com>
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 <jeremy.linton@arm.com>
>
> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
> [2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
> [3] https://lore.kernel.org/all/443104e2-ba6e-454e-8469-909f35817a99@huawei.com/
> [4] https://lore.kernel.org/all/317d33d5-8279-4aa8-84b7-6ae1976636ac@huawei.com/
>
> Tested-by: Sumit Gupta <sumitg@nvidia.com>
> Reviewed-by: Sumit Gupta <sumitg@nvidia.com>
> Tested-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
> Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
> ---
> 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/20260410094145.4132082-1-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 | 92 ++++++++++++++++++++++++++++++++----
> drivers/acpi/cppc_acpi.c | 50 ++++++++++++++++++--
> include/acpi/cppc_acpi.h | 7 +++
> 3 files changed, 136 insertions(+), 13 deletions(-)
>
next prev parent reply other threads:[~2026-07-09 6:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 8:28 [PATCH v2 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64 Pengjie Zhang
2026-07-08 8:28 ` [PATCH v2 1/2] ACPI: CPPC: add paired FFH feedback-counter read hook Pengjie Zhang
2026-07-08 8:28 ` [PATCH v2 2/2] arm64: topology: read CPPC FFH feedback counters in one operation Pengjie Zhang
2026-07-09 6:11 ` Jeremy Linton
2026-07-10 13:35 ` Beata Michalska
2026-07-09 6:07 ` Jeremy Linton [this message]
2026-07-10 13:42 ` [PATCH v2 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64 Beata Michalska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29947b61-d2f3-4161-ac65-197cfe00a99d@arm.com \
--to=jeremy.linton@arm.com \
--cc=acpica-devel@lists.linux.dev \
--cc=beata.michalska@arm.com \
--cc=catalin.marinas@arm.com \
--cc=cuiyunhui@bytedance.com \
--cc=geert+renesas@glider.be \
--cc=ionela.voinescu@arm.com \
--cc=lenb@kernel.org \
--cc=lihuisong@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=prime.zeng@hisilicon.com \
--cc=rafael@kernel.org \
--cc=saket.dumbre@intel.com \
--cc=sumitg@nvidia.com \
--cc=vanshikonda@os.amperecomputing.com \
--cc=viresh.kumar@linaro.org \
--cc=wanghuiqiang@huawei.com \
--cc=wangzhi12@huawei.com \
--cc=will@kernel.org \
--cc=xuwei5@huawei.com \
--cc=yubowen8@huawei.com \
--cc=zhangpengjie2@huawei.com \
--cc=zhanjie9@hisilicon.com \
--cc=zhenglifeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.