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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3607404.iIbC2pHGDl@rjwysocki.net>
Date: Fri, 08 Nov 2024 17:09:47 +0100
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>,
 Peter Zijlstra <peterz@...radead.org>,
 Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
 Len Brown <len.brown@...el.com>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Morten Rasmussen <morten.rasmussen@....com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Subject:
 [RFC][PATCH v0.1 0/6] cpufreq: intel_pstate: Enable EAS on hybrid platforms
 without SMT

Hi Everyone,

This series, on top of

https://lore.kernel.org/linux-pm/12554508.O9o76ZdvQC@rjwysocki.net/

modifies the energy model code, the EAS setup code and the intel_pstate
driver to enable simplified EAS support in the latter.

The underlying observation is that on the platforms targeted by these changes,
Lunar Lake at the time of this writing, the "small" CPUs (E-cores), when run at
the same performance level, are always more energy-efficient than the "big" or
"performance" CPUs (P-cores).  This means that, regardless of the scale-
invariant utilization of a task, as long as there is enough spare capacity on
E-cores, the relative cost of running it there is always lower.

Thus the idea is to register a perf domain per CPU type, which currently are
P-cores and E-cores, to represent the relative costs of running tasks on CPUs
of each type.  The states table in each of these perf domains is one-element
and that element only contains the cost value, which causes EAS to compare the
"E-core cost" with the "P-core cost" every time it has to make a decision, and
because the "E-core cost" is lower, it will always prefer E-cores as long as
there is enough spare capacity to run the given task on one of them.

The intel_pstate driver knows the type of each CPU, so it can create cpumasks
requisite for registering the perf domains as per the above, but the energy
model registration code needs to be adjusted to handle perf domains with
one-element states tables (further referred to as stub perf domains).  It
also needs to allow adding a new CPU to an existing perf domain to handle the
case in which some CPUs are offline to start with and are brought online later
via sysfs.  The first 4 patches in the series make the requisite energy model
change.

Patch [5/6] updates the EAS setup code to allow it to work without the
schedutil cpufreq govenor which need not be used when intel_pstate is in
use (in the "active" mode, intel_pstate uses a built-in governor that can
work with EAS just fine because it also adjusts the CPU performance level to
utilization).

The last patch modifies intel_pstate to register the perf domains described
above and update them when new CPUs become available for the first time.

Please refer to the individual patch changelogs for details.

It has been verified that the behavior after the changes here is as intended,
that is the perf domains are registered and EAS is enabled.

For easier access, the series is available on the intel_pstate-experimental-v2
branch in linux-pm.git:

https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=intel_pstate-experimental-v2

Thanks!




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ