linux-kernel - Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs

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: <aIso4kLtChiQkBjH@arm.com>
Date: Thu, 31 Jul 2025 10:27:14 +0200
From: Beata Michalska <beata.michalska@....com>
To: Prashant Malani <pmalani@...gle.com>
Cc: Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Jie Zhan <zhanjie9@...ilicon.com>,
	Ionela Voinescu <ionela.voinescu@....com>,
	Ben Segall <bsegall@...gle.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:CPU FREQUENCY SCALING FRAMEWORK" <linux-pm@...r.kernel.org>,
	Mel Gorman <mgorman@...e.de>, Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Valentin Schneider <vschneid@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	z00813676 <zhenglifeng1@...wei.com>, sudeep.holla@....com
Subject: Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs

On Wed, Jul 30, 2025 at 12:31:33AM -0700, Prashant Malani wrote:
> Sorry for restarting this thread, but I think the solution submitted
> solves the write path. The read path still needs addressing.
> 
> As such, given the limitations and scheduler uncertainties
> around the reads of the FFH registers, I think the patch in this
> thread is still a good optimization to include; namely, if we know
> the CPU is idle, don't bother trying to wake up that CPU just to
> calculate frequency.
> 
I am still wondering whether cpufreq core is not a better suited place for
checking whether the CPU is idle. We could potentially try on anther CPU within
the policy and if there is none, just provide the last known freq ?

@Viresh: What are your thoughts on that ?

In the meantime I'm still trying to figure out smht to mitigate the issues with
the numbers we get from counters after waking up the CPU.

---
BR
Beata
> 
> On Mon, 21 Jul 2025 at 23:02, Prashant Malani <pmalani@...gle.com> wrote:
> >
> > Hi Viresh and Rafael,
> >
> > Thank you for taking the time to look at this series.
> >
> > On Mon, 21 Jul 2025 at 20:27, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> > >
> > > On 21-07-25, 12:40, Prashant Malani wrote:
> > > > On Mon, 21 Jul 2025 at 10:00, Rafael J. Wysocki <rafael@...nel.org> wrote:
> > > > > Why don't you flag the driver as CPUFREQ_NEED_UPDATE_LIMITS?
> > > > >
> > > > > That would kind of make sense given how the driver works overall, or
> > > > > am I missing anything?
> > >
> > > +1
> >
> > Thanks, I posted [1] which implements what's suggested by Rafael. PTAL
> >
> > Best regards,
> >
> > [1] https://lore.kernel.org/linux-pm/20250722055611.130574-2-pmalani@google.com/
> >
> > --
> > -Prashant
> 
> 
> 
> -- 
> -Prashant