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: <CAFivqm+hjfDwPJCiHavnZSg2D+OaP5xbQnidmwxQ3HD32ic6EA@mail.gmail.com>
Date: Thu, 19 Jun 2025 22:07:23 -0700
From: Prashant Malani <pmalani@...gle.com>
To: Jie Zhan <zhanjie9@...ilicon.com>
Cc: 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>, 
	Ionela Voinescu <ionela.voinescu@....com>, Beata Michalska <beata.michalska@....com>, 
	z00813676 <zhenglifeng1@...wei.com>
Subject: Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs

Hi Jie,

Thanks for taking a look at the patch.

On Thu, 19 Jun 2025 at 20:53, Jie Zhan <zhanjie9@...ilicon.com> wrote:
> On 19/06/2025 08:09, Prashant Malani wrote:
> > AMU performance counters tend to be inaccurate when measured on idle CPUs.
> > On an idle CPU which is programmed to 3.4 GHz (verified through firmware),
> > here is a measurement and calculation of operating frequency:
> >
> > t0: ref=899127636, del=3012458473
> > t1: ref=899129626, del=3012466509
> > perf=40
>
> In this case, the target cpu is mostly idle but not fully idle during the
> sampling window since the counter grows a little bit.
> Perhaps some interrupts happen to run on the cpu shortly.
>
> Thus, the actual issue is the accuracy of frequency sampling becomes poor
> when the delta of counters are too small to obtain a reliable accuracy.
>
> Would it be more sensible to put a minimum threshold of the delta of
> counters when sampling the frequency?

I'm happy to throw together a patch if there is some safe
threshold the experts here can agree on for the minimum delta for
the ref counter. I would caution that with this sort of approach we
start running into the familiar issue:
- What value is appropriate? Too large and you get false
positives (falling back to the idle invalid path when we shouldn't), and
too less and you get false negatives (we still report inaccurate
counter values).
- Is the threshold the same across platforms?
- Will it remain the same 5/10 years from now?

>  BTW, that ABI
> doesn't seem to be synchronous at all, i.e. the cpu might be busy when we
> check and then become idle when sampling.
>

I don't think this is necessarily an issue. The ABI doesn't need to be
synchronous; it is merely a snapshot of the scheduler view of that CPU
at a point in time. Even the current method of perf counters sampling
is purely hueristic. The CPU might be idle for the 2 usec the
sampling is done, and servicing traffic before and after that.
This is inherent whenever you are sampling any system state.

I would imagine it is more reliable to trust the kernel scheduler's view
of whether a CPU is idle, than relying on counters and a calculation
method which are sensitive and unreliable for idle systems
(i.e stray interrupts can throw off the calculations).

That said, I'm happy to go with the approach folks on this list recommend.

Cheers,

-- 
-Prashant