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] [day] [month] [year] [list]

Message-ID: <CAFivqmKBgYVa6JUh82TS2pO915PUDYZMH+k-5=-0u1-K9-gMMw@mail.gmail.com>
Date: Wed, 9 Jul 2025 15:49:03 -0700
From: Prashant Malani <pmalani@...gle.com>
To: Beata Michalska <beata.michalska@....com>
Cc: 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>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Steven Rostedt <rostedt@...dmis.org>, Valentin Schneider <vschneid@...hat.com>, 
	Vincent Guittot <vincent.guittot@...aro.org>, Viresh Kumar <viresh.kumar@...aro.org>, 
	z00813676 <zhenglifeng1@...wei.com>
Subject: Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs

On Wed, 9 Jul 2025 at 10:25, Prashant Malani <pmalani@...gle.com> wrote:
>
> Hi Beata,
>
> Thanks for taking a look.
>
> On Mon, 7 Jul 2025 at 01:33, Beata Michalska <beata.michalska@....com> wrote:
> >
> > Hi Prashant,
> >
> > On Wed, Jul 02, 2025 at 11:38:11AM -0700, Prashant Malani wrote:
> > > Hi All,
> > >
> > > Ionela, Beata, could you kindly review ?
> > >
> > > On Fri, 27 Jun 2025 at 10:07, Prashant Malani <pmalani@...gle.com> wrote:
> > > >
> > >
> > > I think it is pertinent to note: the actual act of reading the CPPC counters
> > > will (at least for ACPI_ADR_SPACE_FIXED_HARDWARE counters)
> > > wake the CPU up, so even if a CPU *was* idle, the reading of the counters
> > > calls cpc_read_ffh() [1] which does an IPI on the target CPU [2] thus waking
> > > it up from WFI.
> > >
> > > And that brings us back to the original assertion made in this patch:
> > > the counter values are quite unreliable when the CPU is in this
> > > idle (or rather I should correct that to, waking from WFI) state.
> > >
> > I'd say that's very platform specific, and as such playing with the delay makes
> > little sense. I'd need to do more deliberate testing, but I haven't noticed
> > (yet) any discrepancies in AMU counters on waking up.
> > Aside, you have mentioned that you've observed the frequency reported to be
> > above max one (4GHz vs 3.5HZ if I recall correctly) - shouldn't that be clamped
> > by the driver if the values are outside of supported range ?
> >
> > Verifying whether the CPU is idle before poking it just to get a counters
> > reading to derive current frequency from those does feel rather like an
> > appealing idea.
>
> That's good to hear. What can we do to refine this series further?
>
> > Narrowing the scope for ACPI_ADR_SPACE_FIXED_HARDWARE cases
> > could be solved by providing a query for the address space. Though I am not an
> > expert here so would be good to get some input from someone who is
> > (on both).
>
> Who would be the expert here (are they on this mailing list)?
>
> Could you point me to an example for the query for the address space? Then
> I can respin this series to use that query and narrow the scope.

Actually, if the idea of this optimization (the idle_cpu check) sounds
good to you,
I don't see why we should limit it to ACPI_ADR_SPACE_FIXED_HARDWARE.
IOW, the patch can remain in its current form.

Best regards,

-- 
-Prashant