Documentation/admin-guide/pm/cpufreq.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
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
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!
© 2016 - 2024 Red Hat, Inc.