All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)
> 


  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.