[PATCH] cpufreq: docs: Reflect latency changes in docs

[PATCH] cpufreq: docs: Reflect latency changes in docs

[Christian Loehle]

There were two changes related to transition latency recently.
Namely commit e13aa799c2a6 ("cpufreq: Change default transition delay
to 2ms") and
commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER").

Both changed the defaults / maximums so let the documentation
reflect that.

Signed-off-by: Christian Loehle <christian.loehle@arm.com>
---
 Documentation/admin-guide/pm/cpufreq.rst | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index fe1be4ad88cb..a21369eba034 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -425,8 +425,8 @@ 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: 1000 times the scaling driver's
-	transition latency).
+	runs of governor computations (default: 1.5 times the scaling driver's
+	transition latency or the maximum 2ms).
 
 	The purpose of this tunable is to reduce the scheduler context overhead
 	of the governor which might be excessive without it.
@@ -474,17 +474,17 @@ This governor exposes the following tunables:
 	This is how often the governor's worker routine should run, in
 	microseconds.
 
-	Typically, it is set to values of the order of 10000 (10 ms).  Its
-	default value is equal to the value of ``cpuinfo_transition_latency``
-	for each policy this governor is attached to (but since the unit here
-	is greater by 1000, this means that the time represented by
-	``sampling_rate`` is 1000 times greater than the transition latency by
-	default).
+	Typically, it is set to values of the order of 2000 (2 ms).  Its
+	default value is to add a 50% breathing room
+	to ``cpuinfo_transition_latency`` on each policy this governor is
+	attached to. The minimum is typically the length of two scheduler
+	ticks.
 
 	If this tunable is per-policy, the following shell command sets the time
-	represented by it to be 750 times as high as the transition latency::
+	represented by it to be 1.5 times as high as the transition latency
+	(the default)::
 
-	# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate
+	# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
 
 ``up_threshold``
 	If the estimated CPU load is above this value (in percent), the governor
-- 
2.34.1

Re: [PATCH] cpufreq: docs: Reflect latency changes in docs

[Rafael J. Wysocki]

On Fri, Oct 18, 2024 at 12:00 AM Christian Loehle
<christian.loehle@arm.com> wrote:
>
> There were two changes related to transition latency recently.
> Namely commit e13aa799c2a6 ("cpufreq: Change default transition delay
> to 2ms") and
> commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER").
>
> Both changed the defaults / maximums so let the documentation
> reflect that.
>
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> ---
>  Documentation/admin-guide/pm/cpufreq.rst | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
> index fe1be4ad88cb..a21369eba034 100644
> --- a/Documentation/admin-guide/pm/cpufreq.rst
> +++ b/Documentation/admin-guide/pm/cpufreq.rst
> @@ -425,8 +425,8 @@ 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: 1000 times the scaling driver's
> -       transition latency).
> +       runs of governor computations (default: 1.5 times the scaling driver's
> +       transition latency or the maximum 2ms).
>
>         The purpose of this tunable is to reduce the scheduler context overhead
>         of the governor which might be excessive without it.
> @@ -474,17 +474,17 @@ This governor exposes the following tunables:
>         This is how often the governor's worker routine should run, in
>         microseconds.
>
> -       Typically, it is set to values of the order of 10000 (10 ms).  Its
> -       default value is equal to the value of ``cpuinfo_transition_latency``
> -       for each policy this governor is attached to (but since the unit here
> -       is greater by 1000, this means that the time represented by
> -       ``sampling_rate`` is 1000 times greater than the transition latency by
> -       default).
> +       Typically, it is set to values of the order of 2000 (2 ms).  Its
> +       default value is to add a 50% breathing room
> +       to ``cpuinfo_transition_latency`` on each policy this governor is
> +       attached to. The minimum is typically the length of two scheduler
> +       ticks.
>
>         If this tunable is per-policy, the following shell command sets the time
> -       represented by it to be 750 times as high as the transition latency::
> +       represented by it to be 1.5 times as high as the transition latency
> +       (the default)::
>
> -       # echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate
> +       # echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
>
>  ``up_threshold``
>         If the estimated CPU load is above this value (in percent), the governor
> --

Applied as 6.12-rc material, thanks!