linux-kernel - Re: [PATCH] cpufreq: CPPC: Increase delay between perf counter reads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aKY0xuegI1S4X2uW@arm.com>
Date: Wed, 20 Aug 2025 22:49:10 +0200
From: Beata Michalska <beata.michalska@....com>
To: Prashant Malani <pmalani@...gle.com>
Cc: Yang Shi <yang@...amperecomputing.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:CPU FREQUENCY SCALING FRAMEWORK" <linux-pm@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Ionela Voinescu <Ionela.Voinescu@....com>
Subject: Re: [PATCH] cpufreq: CPPC: Increase delay between perf counter reads

On Tue, Aug 19, 2025 at 04:43:59PM -0700, Prashant Malani wrote:
> On Tue, 19 Aug 2025 at 02:29, Beata Michalska <beata.michalska@....com> wrote:
> >
> > 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@...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.
> 
> Thanks for the correction. I made an error in understanding the code.
> 
> >
> > > - The central accuracy issue behind cpuinfo_cur_freq still needs to be handled.
> > I'd really discourage increasing the sampling period for cppc.
> 
> The only true solution is to make the register reads (ref + delivered
> combined) atomic.
> We see that this solves the issue when conducting the same
> measurements on firmware
> (which is an RTOS, so no scheduler randomness).
Kinda working on that one.
> 
> Outside of that, I can't think of another mitigation beyond adding delay to make
> the time deltas not matter so much.
I'm not entirely sure what 'so much' means in this context.
How one would quantify whether the added delay is actually mitigating the issue?

> 
> Perhaps ARM should introduce a "snapshot" feature which takes the snapshot
> of the AMU counters on a register write; IAC that's outside the scope
What do you mean by register write ?
> of this discussion.
> 
> Could you kindly explain why adding the udelay here is discouraged?

Would you mind clarifying how the specific value of 200 µs was determined?
Was it carefully derived from measurements across multiple platforms and
workloads, or simply observed to “work” on one relatively stable setup?

Understanding the basis for choosing that delay will help put the discussion
into the right context.

---
BR
Beata
> 
> Best regards,
> 
> -- 
> -Prashant