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: <CAFivqmKR1dqVqTsoznH2-n8cyAM1=5zEGcEvmESU8RNGac-0sA@mail.gmail.com>
Date: Fri, 1 Aug 2025 02:16:08 -0700
From: Prashant Malani <pmalani@...gle.com>
To: Beata Michalska <beata.michalska@....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

HI Beata,

On Thu, 31 Jul 2025 at 13:31, Beata Michalska <beata.michalska@....com> wrote:

> Thank you for the info, but I'm exploring ways that will not increase the time
> window between the reads.

IMO this issue is intractable on non-RT OSes like Linux (at least,
Linux when it is not compiled for RT), since we basically need to
ensure atomicity for the reading of both ref and del registers together.
We can't disable preemption here, since some of
the code paths (like PCC regs) acquire semaphores [2].

This also explains why we don't see this issue while reading the same
registers from firmware (running an RTOS). There, the same readings
are accurate (whether the CPU is idle or loaded).

So mitigations like increasing the delay are the only practical recourse.
IAC, I hope this doesn't detract from the discussion regarding the patch
series in this thread, which is about the idle optimization
(which I think we should pursue).

> While we are at it, would you be able to drop me some numbers from your
> platform, preferably good and `bad` ones:
> both counter values, and the bits that are used for mapping performance to
> actual frequency (nominal freq/perf, reference perf)

Sure. There are two pathological scenarios.
The first is when the CPU is idle/mostly idle. Here are some counter readings
(I used ftrace for all of these, and the max possible frequency is 3.4GHz):

t0: del:2936200649, ref:972155370
t1: del:2936208538, ref:972157370
ref_perf:10
delivered_perf:39

t0: del:1733705541, ref:518550840
t1: del:1733713524, ref:518552820
ref_perf:10
delivered_perf:40

This scenario is handled by this patch series.

The second is the heavily loaded CPU case.
Here are the counter readings:
t0: del:93896505680, ref:27625620970
t1: del:93896521640, ref:27625625360
ref_perf:10
delivered_perf:36

t0: del:94258513479, ref:27795493670
t1: del:94258529230, ref:27795498090
ref_perf:10
delivered_perf:35

These aren't as bad, but still above the stated maximum.
These get addressed by [1].

And here is a "good" measurement when the CPU is loaded:
t0: del:102081104909, ref:30074917840
t1: del:102081121558, ref:30074922660
ref_perf:10
delivered_perf:34

HTH,

-Prashant

[1] https://lore.kernel.org/linux-pm/20250730220812.53098-1-pmalani@google.com/
[2] https://elixir.bootlin.com/linux/v6.16-rc7/source/drivers/acpi/cppc_acpi.c#L1509

-- 
-Prashant