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: <8c9fc3d2-991d-4caa-8773-418bea0fdf21@gmail.com>
Date: Thu, 22 May 2025 06:15:32 -0500
From: Russell Haley <yumpusamongus@...il.com>
To: Shashank Balaji <shashank.mahadasyam@...y.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

On 5/22/25 4:46 AM, Shashank Balaji wrote:
> Hi Russell,
> 
> 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.

If setting frequencies on a per-CPU basis is how you discovered this,
you may find it to be a source of more automagic. There are a lot of
client processors that cannot (usefully) have different frequency
targets for each CPU, because there is only one voltage regulator. In
that case, slowing any CPU down would only harm its performance (and
efficiency, because race-to-sleep). So, the global frequency target is
taken as the maximum of the per-CPU targets.

Cheers,
Russell