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: <CAJZ5v0i6i6xt5-QOU2r0MDxR+7aOXYBUJ4kkJFQg6+RekayTNQ@mail.gmail.com>
Date: Thu, 22 May 2025 11:56:22 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Shashank Balaji <shashank.mahadasyam@...y.com>
Cc: Russell Haley <yumpusamongus@...il.com>, "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

On Thu, May 22, 2025 at 11:46 AM Shashank Balaji
<shashank.mahadasyam@...y.com> wrote:
>
> 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.

This wouldn't work the way you expect, though.  It would cause the
driver to always set the frequency to policy->max.

> > 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.

That's not true.

scaling_min_freq and scaling_max_freq is per CPU, but the values from
there are subject to hardware coordination.

> Whereas, the userspace governor can be set on a per-cpu basis.

This is also subject to hardware coordination.

> 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".

The documentation can be adjusted by replacing "set" with "request" in
the userspace governor description and adding a clarification to it
that the requested frequency is between the policy min and max levels.

With HWP enabled, the closest to setting the frequency to a specific
value one can get is by setting scaling_min_freq and scaling_max_freq
to that value.