[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0iBHEA3PPST1TxUbBrJKYxwb89GU6JzqRz1QkzmU_j_Uw@mail.gmail.com>
Date: Mon, 21 Oct 2024 13:25:36 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Christian Loehle <christian.loehle@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Qais Yousef <qyousef@...alina.io>,
Viresh Kumar <viresh.kumar@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, linux-pm <linux-pm@...r.kernel.org>,
"corbet@....net" <corbet@....net>
Subject: Re: [PATCH] cpufreq: docs: Reflect latency changes in docs
On Fri, Oct 18, 2024 at 12:00 AM Christian Loehle
<christian.loehle@....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@....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!
Powered by blists - more mailing lists