linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aC7yeQvKVQ1No9EW@JPC00244420>
Date: Thu, 22 May 2025 18:46:33 +0900
From: Shashank Balaji <shashank.mahadasyam@...y.com>
To: Russell Haley <yumpusamongus@...il.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Jonathan Corbet <corbet@....net>, linux-pm@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Shinya Takumi <shinya.takumi@...y.com>
Subject: Re: [PATCH] cpufreq, docs: (userspace governor) add that actual freq
 is >= scaling_setspeed

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
"