linux-kernel - [PATCH v2] cpufreq: Handle CPUFREQ_ETERNAL with a default transition latency

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

Message-ID: <20250922125929.453444-1-shawnguo2@yeah.net>
Date: Mon, 22 Sep 2025 20:59:21 +0800
From: Shawn Guo <shawnguo2@...h.net>
To: "Rafael J . Wysocki" <rafael@...nel.org>
Cc: Shawn Guo <shawnguo@...nel.org>,
	Qais Yousef <qyousef@...alina.io>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: [PATCH v2] cpufreq: Handle CPUFREQ_ETERNAL with a default transition latency

From: Shawn Guo <shawnguo@...nel.org>

A regression is seen with 6.6 -> 6.12 kernel upgrade on platforms where
cpufreq-dt driver sets cpuinfo.transition_latency as CPUFREQ_ETERNAL (-1),
due to that platform's DT doesn't provide the optional property
'clock-latency-ns'.  The dbs sampling_rate was 10000 us on 6.6 and
suddently becomes 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these
platforms, because the default transition delay was dropped by the commits
below.

  commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER")
  commit a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us")
  commit e13aa799c2a6 ("cpufreq: Change default transition delay to 2ms")

It slows down dbs governor's reacting to CPU loading change
dramatically.  Also, as transition_delay_us is used by schedutil governor
as rate_limit_us, it shows a negative impact on device idle power
consumption, because the device gets slightly less time in the lowest OPP.

Fix the regressions by defining a default transition latency for
handling the case of CPUFREQ_ETERNAL.

Cc: stable@...r.kernel.org
Fixes: 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER")
Signed-off-by: Shawn Guo <shawnguo@...nel.org>
---
Changes for v2:
- Follow Rafael's suggestion to define a default transition latency for
  handling CPUFREQ_ETERNAL, and pave the way to get rid of
  CPUFREQ_ETERNAL completely later.

v1: https://lkml.org/lkml/2025/9/10/294

 drivers/cpufreq/cpufreq.c | 3 +++
 include/linux/cpufreq.h   | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fc7eace8b65b..c69d10f0e8ec 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -549,6 +549,9 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy)
 	if (policy->transition_delay_us)
 		return policy->transition_delay_us;
 
+	if (policy->cpuinfo.transition_latency == CPUFREQ_ETERNAL)
+		policy->cpuinfo.transition_latency = CPUFREQ_DEFAULT_TANSITION_LATENCY_NS;
+
 	latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
 	if (latency)
 		/* Give a 50% breathing room between updates */
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 95f3807c8c55..935e9a660039 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -36,6 +36,8 @@
 /* Print length for names. Extra 1 space for accommodating '\n' in prints */
 #define CPUFREQ_NAME_PLEN		(CPUFREQ_NAME_LEN + 1)
 
+#define CPUFREQ_DEFAULT_TANSITION_LATENCY_NS	NSEC_PER_MSEC
+
 struct cpufreq_governor;
 
 enum cpufreq_table_sorting {
-- 
2.43.0