linux-kernel - Re: [PATCH] cpufreq: docs: Update description of rate_limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jup72gcP4gdJPjYQebwsMrcWC2u0soqekoTQCR0UDEwA@mail.gmail.com>
Date: Tue, 3 Feb 2026 22:19:41 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Yaxiong Tian <tianyaxiong@...inos.cn>
Cc: rafael@...nel.org, viresh.kumar@...aro.org, corbet@....net, 
	skhan@...uxfoundation.org, linux-pm@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: docs: Update description of rate_limit_us
 default value

On Tue, Feb 3, 2026 at 10:35 AM Yaxiong Tian <tianyaxiong@...inos.cn> wrote:
>
> 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.
> --

Applied as 6.20/7.0 material, thanks!