| Message ID | 46853b6e-bad5-4ace-9b23-ff157f234ae3@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | cpufreq: docs: Reflect latency changes in docs | expand |
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!
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
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(-)