Hi Russell,
On Thu, May 22, 2025 at 03:50:55AM -0500, Russell Haley wrote:
> If the user asks for the frequency to be set from userspace, the
> frequency had damn well better be set from userspace.
First of all, I agree with you. In fact, before sending this patch, I
was considering adding CPUFREQ_GOV_STRICT_TARGET to the userspace
governor. intel_pstate should handle the rest of it.
> In my opinion, the documentation is correct, and it is the
> implementation in intel_pstate that is wrong. If the user wanted two
> separate knobs that control the minimum and maximum frequencies, they
> could leave intel_pstate in "active" mode and change scaling_min_freq
> and scaling_max_freq.
If intel_pstate is left in "active" mode, then userspace can't use any
of the other governors. Moreover, intel_pstate's min and max frequencies
apply to all the cpus. Whereas, the userspace governor can be set on a
per-cpu basis.
Let's say this is "fixed" by adding CPUFREQ_GOV_STRICT_TARGET flag to
the userspace governor. Then userspace has no way to get back the
current behavior where the hardware automagically increases frequency
beyond the target frequency. At least not without a new interface.
With the current behaviour, userspace can have it both ways:
- actual frequency = target frequency
- actual frequency >= target frequency
And the occasional higher frequency shouldn't hurt performance, right?
But if they still want exact equality, with the current interface, they
can do that too.
This consideration is what led me to document the "actual freq >= target
freq" rather than patch it so that "actual freq = target freq".
Thanks
Regards,
Shashank
"
