From: Breno Leitao <leitao@debian.org>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Jie Zhan <zhanjie9@hisilicon.com>,
Lifeng Zheng <zhenglifeng1@huawei.com>,
Pierre Gondois <pierre.gondois@arm.com>,
Sumit Gupta <sumitg@nvidia.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
dcostantino@meta.com, pjaroszynski@nvidia.com, Al.Grant@arm.com,
linux-arm-kernel@lists.infradead.org, kernel-team@meta.com
Subject: Re: [PATCH] cpufreq: cppc: discard out-of-range delivered_perf samples
Date: Tue, 5 May 2026 05:52:21 -0700 [thread overview]
Message-ID: <afnnPRZBdWlriZON@gmail.com> (raw)
In-Reply-To: <7e55dd1e-2841-4918-8e3d-82203a70451a@arm.com>
Hello Jeremy,
On Fri, May 01, 2026 at 12:41:45PM -0500, Jeremy Linton wrote:
> A little jitter over, is probably expected. If that is what is happening
> then clamping to highest_perf makes sense instead.
Based on my analysis of the code, interrupts appear to remain enabled
during the delay, which could introduce significant jitter if an IRQ
fires during that window.
I'd be interested in testing this under an IRQ storm to quantify the
actual impact on the measurements.
> But then, this is really
> a sampling problem so does it go away if you double the udelay slightly.
> Maybe the udelay value should be proportional to the reference_perf value?
That's a reasonable approach. What would you suggest for the
implementation?
I considered making it a kernel or module parameter, but I'm not certain
that's the best solution, since the "user" might not know what to
set/use.
Thanks for your review,
--breno
prev parent reply other threads:[~2026-05-05 13:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 16:32 [PATCH] cpufreq: cppc: discard out-of-range delivered_perf samples Breno Leitao
2026-05-01 17:41 ` Jeremy Linton
2026-05-05 12:52 ` 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=afnnPRZBdWlriZON@gmail.com \
--to=leitao@debian.org \
--cc=Al.Grant@arm.com \
--cc=dcostantino@meta.com \
--cc=jeremy.linton@arm.com \
--cc=kernel-team@meta.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pierre.gondois@arm.com \
--cc=pjaroszynski@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox