From: Beata Michalska <beata.michalska@arm.com>
To: Prashant Malani <pmalani@google.com>
Cc: Yang Shi <yang@os.amperecomputing.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:CPU FREQUENCY SCALING FRAMEWORK"
<linux-pm@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Ionela Voinescu <Ionela.Voinescu@arm.com>
Subject: Re: [PATCH] cpufreq: CPPC: Increase delay between perf counter reads
Date: Tue, 19 Aug 2025 11:28:38 +0200 [thread overview]
Message-ID: <aKRDxhirzwEPxaqd@arm.com> (raw)
In-Reply-To: <CAFivqmKZcipdc1P1b7jkNTBAV-WE4bSeW8z=eHHmtHBxuErZiQ@mail.gmail.com>
On Tue, Aug 05, 2025 at 06:00:09PM -0700, Prashant Malani wrote:
> Thanks Yang,
>
> On Tue, 5 Aug 2025 at 17:26, Yang Shi <yang@os.amperecomputing.com> wrote:
> > Thank you for cc'ing me the patch. I posted the similar patch ago and
> > had some discussion on the mailing list. Then someone else from ARM
> > pursued a different way to solve it. But I didn't follow very closely.
> > If I remember correctly, a new sysfs interface, called cpuinfo_avg_freq
> > was added. It should be the preferred way to get cpu frequency. Please
> > see
> > https://github.com/torvalds/linux/commit/fbb4a4759b541d09ebb8e391d5fa7f9a5a0cad61.
> >
> > Added Beata Michalska in the loop too, who is the author of the patch.
> > Please feel free to correct me, if I'm wrong.
>
> Thanks for the additional context. Yeah, the issue is that :
> - The new sysfs node is sampling period is too long (20ms) [1]
> That makes it problematic for userspace use cases, so we need something
> which takes less time.
That actually specifies the duration, for which the most recently acquired
sample is considered valid. Sampling is tick-based.
> - The central accuracy issue behind cpuinfo_cur_freq still needs to be handled.
I'd really discourage increasing the sampling period for cppc.
---
BR
Beata
>
> [1] https://elixir.bootlin.com/linux/v6.16/source/arch/arm64/kernel/topology.c#L283
>
>
> --
> -Prashant
next prev parent reply other threads:[~2025-08-19 9:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 22:07 [PATCH] cpufreq: CPPC: Increase delay between perf counter reads Prashant Malani
2025-08-06 0:26 ` Yang Shi
2025-08-06 1:00 ` Prashant Malani
2025-08-19 9:28 ` Beata Michalska [this message]
2025-08-19 23:43 ` Prashant Malani
2025-08-20 20:49 ` Beata Michalska
2025-08-20 21:25 ` Prashant Malani
2025-08-25 14:52 ` Beata Michalska
2025-08-25 20:24 ` Prashant Malani
2025-08-28 7:33 ` Beata Michalska
2025-08-28 21:29 ` Prashant Malani
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=aKRDxhirzwEPxaqd@arm.com \
--to=beata.michalska@arm.com \
--cc=Ionela.Voinescu@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pmalani@google.com \
--cc=rafael@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=yang@os.amperecomputing.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.