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: <CAJZ5v0gz3Y+RGqBf9E1hzq9rwfrryd98Xpk51DtLd-uck5y-rw@mail.gmail.com>
Date: Thu, 22 May 2025 11:47:04 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Russell Haley <yumpusamongus@...il.com>
Cc: Shashank Balaji <shashank.mahadasyam@...y.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 10:51 AM Russell Haley <yumpusamongus@...il.com> wrote:
>
>
> On 5/22/25 3:05 AM, Shashank Balaji wrote:
> > 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.
> >
>
> 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 the user asks for the frequency to be set from userspace, the
> frequency had damn well better be set from userspace.

The userspace governor requests a frequency between policy->min and
policy->max on behalf of user space.  In intel_pstate this translates
to setting DESIRED_PERF to the requested value which is also the case
for the other governors.

There is no guarantee that the request will be granted by the
hardware, either way.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ