From: Breno Leitao <leitao@debian.org>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: linux-pm@vger.kernel.org, sumitg@nvidia.com,
pierre.gondois@arm.com, zhenglifeng1@huawei.com,
zhanjie9@hisilicon.com, viresh.kumar@linaro.org,
rafael@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpufreq: cppc: Reduce cppc delivered perf sampling jitter
Date: Thu, 4 Jun 2026 02:42:10 -0700 [thread overview]
Message-ID: <aiFHsZ_Ha1DKIm8N@gmail.com> (raw)
In-Reply-To: <20260602212052.1278365-1-jeremy.linton@arm.com>
On Tue, Jun 02, 2026 at 04:20:52PM -0500, Jeremy Linton wrote:
> CPPC uses a pair of registers cycling at different frequencies to
> determine an accumulated performance level. For userspace reporting we
> want to convert this to an instantaneous CPU frequency, but over short
> time periods small errors caused by CPPC counter reads can cause
> fairly significant reported frequency variations even when the core
> CPU clock isn't changing.
>
> Reduce this by keeping a start sample fixed and retrying the end
> sample until the counter deltas are large enough to reduce short
> window error, or until adjacent delivered performance estimates are
> within the CPU's observed CPPC read noise floor.
>
> To begin, resample the initial pair a small fixed number of times
> looking for matching delivered performance deltas. This reduces the
> chance that a disturbed start sample anchors the rest of the
> calculation.
>
> Then look for an end sample while updating the noise floor from the
> best error seen between samples. The floor remains zero on systems
> with stable feedback reads, but lets noisy systems stop early once
> another retry is unlikely to improve the result. The retry loop is
> capped at 200 iterations, giving an ~20 usec explicit delay budget
> derived from ndelay(100).
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Breno Leitao <leitao@debian.org>
I've tested this on my grace host, checking "cat
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq" thousand times,
and the result is quite good, reducing the Std Dev by 5x, and getting
a better value.
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
3339000
Baseline:
Average: 3505050.00
P50 (Median): 3388500.00
Std Dev: 462607.66
Min: 2709000.00
Max: 4464000.00
Wth this patch:
Average: 2393550.00
P50 (Median): 2394000.00
Std Dev: 68629.06
Min: 2241000.00
Max: 2529000.00
Thanks,
--breno
prev parent reply other threads:[~2026-06-04 9:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 21:20 [PATCH] cpufreq: cppc: Reduce cppc delivered perf sampling jitter Jeremy Linton
2026-06-03 10:54 ` Breno Leitao
2026-06-03 16:46 ` Jeremy Linton
2026-06-04 8:12 ` Breno Leitao
2026-06-04 9:42 ` Breno Leitao [this message]
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=aiFHsZ_Ha1DKIm8N@gmail.com \
--to=leitao@debian.org \
--cc=jeremy.linton@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=sumitg@nvidia.com \
--cc=viresh.kumar@linaro.org \
--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.