[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260203093501.1138721-1-tianyaxiong@kylinos.cn>
Date: Tue, 3 Feb 2026 17:35:01 +0800
From: Yaxiong Tian <tianyaxiong@...inos.cn>
To: rafael@...nel.org,
viresh.kumar@...aro.org,
corbet@....net,
skhan@...uxfoundation.org
Cc: linux-pm@...r.kernel.org,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Yaxiong Tian <tianyaxiong@...inos.cn>
Subject: [PATCH] cpufreq: docs: Update description of rate_limit_us default value
Due to commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER")
updating the acquisition logic of cpufreq_policy_transition_delay_us(),
the original description of 2ms has become inaccurate.
Therefore, update the description of the default value for
rate_limit_us from 2ms to 1ms.
Signed-off-by: Yaxiong Tian <tianyaxiong@...inos.cn>
---
Documentation/admin-guide/pm/cpufreq.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index 738d7b4dc33a..dbe6d23a5d67 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -439,7 +439,7 @@ This governor exposes only one tunable:
``rate_limit_us``
Minimum time (in microseconds) that has to pass between two consecutive
runs of governor computations (default: 1.5 times the scaling driver's
- transition latency or the maximum 2ms).
+ transition latency or 1ms if the driver does not provide a latency value).
The purpose of this tunable is to reduce the scheduler context overhead
of the governor which might be excessive without it.
--
2.25.1
Powered by blists - more mailing lists