@@ -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``
-------------
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@sony.com> --- Documentation/admin-guide/pm/cpufreq.rst | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- base-commit: d608703fcdd9e9538f6c7a0fcf98bf79b1375b60 change-id: 20250522-userspace-governor-doc-86380dbab3d5 Best regards,