linux-kernel - [PATCH] cpufreq, docs: (userspace governor) add that actual freq is >= scaling

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-next>] [day] [month] [year] [list]

Message-Id: <20250522-userspace-governor-doc-v1-1-c8a038e39084@sony.com>
Date: Thu, 22 May 2025 17:05:33 +0900
From: Shashank Balaji <shashank.mahadasyam@...y.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, 
 Viresh Kumar <viresh.kumar@...aro.org>, Jonathan Corbet <corbet@....net>
Cc: linux-pm@...r.kernel.org, linux-doc@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Shinya Takumi <shinya.takumi@...y.com>, 
 Shashank Balaji <shashank.mahadasyam@...y.com>
Subject: [PATCH] cpufreq, docs: (userspace governor) add that actual freq
 is >= scaling_setspeed

The userspace governor does not have the CPUFREQ_GOV_STRICT_TARGET flag, which
means the requested frequency may not strictly be followed. This is true in the
case of the intel_pstate driver with HWP enabled. When programming the
HWP_REQUEST MSR, the min_perf is set to `scaling_setspeed`, and the max_perf
is set to the policy's max. So, the hardware is free to increase the frequency
beyond the requested frequency.

This behaviour can be slightly surprising, given the current wording "allows
userspace to set the CPU frequency". Hence, document this.

Signed-off-by: Shashank Balaji <shashank.mahadasyam@...y.com>
---
 Documentation/admin-guide/pm/cpufreq.rst | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index 3950583f2b1549b27f568632547e22e9ef8bc167..066fe74f856699c8dd6aaf5e135162ce70686333 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -397,8 +397,15 @@ policy limits change after that.
 -------------

 This governor does not do anything by itself.  Instead, it allows user space
-to set the CPU frequency for the policy it is attached to by writing to the
-``scaling_setspeed`` attribute of that policy.
+to set a target CPU frequency for the policy it is attached to by writing to the
+``scaling_setspeed`` attribute of that policy. The actual frequency will be
+greater than or equal to ``scaling_setspeed``, depending on the cpufreq driver.
+For example, if hardware-managed P-states are enabled, then the ``intel_pstate``
+driver will set the minimum frequency to the value of ``scaling_setspeed`` and
+the maximum frequency to the value of ``scaling_max_freq``.  The hardware is
+free to select any frequency between those two values. If this behavior is not
+desired, then ``scaling_max_freq`` should be set to the same value as
+``scaling_setspeed``.

 ``schedutil``
 -------------

---
base-commit: d608703fcdd9e9538f6c7a0fcf98bf79b1375b60
change-id: 20250522-userspace-governor-doc-86380dbab3d5

Best regards,
-- 
Shashank Balaji <shashank.mahadasyam@...y.com>