Message-ID: <2999205.e9J7NaK4W3@rjwysocki.net>
Date: Tue, 06 May 2025 22:32:47 +0200
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>,
 Dietmar Eggemann <dietmar.eggemann@....com>,
 Morten Rasmussen <morten.rasmussen@....com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
 Pierre Gondois <pierre.gondois@....com>,
 Christian Loehle <christian.loehle@....com>
Subject:
 [PATCH v2 0/7] cpufreq: intel_pstate: Enable EAS on hybrid platforms without
 SMT

Hi Everyone,

This is a new (and most likely final) version of

https://lore.kernel.org/linux-pm/3344336.aeNJFYEL58@rjwysocki.net/

The most significant difference between it and the above is that schedutil is
now required for EAS to be enabled, like on the other platforms using EAS,
which means that intel_pstate needs to operate in the passive mode in order
to use it (the most straightforward way to switch it over to the passive mode
is to write "passive" to /sys/devices/system/cpu/intel_pstate/status).

Accordingly, the changes that were needed for EAS to work without schedutil are
not needed any more, so there is one patch less in the series because of that
and patch [5/7] is simpler than its previous version because some changes made
by it are not necessary any more.

Another patch that has been dropped is

https://lore.kernel.org/linux-pm/1964444.taCxCBeP46@rjwysocki.net/

because it didn't take CPU online into account properly and it is not essential
for the current hardware anyway.

There is a new patch, [7/7], which adds CAS/EAS/hybrid support description to
the intel_pstate admin-guide documentation.

The following paragraph from the original cover letter still applies:

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

The first 2 patches depend on the current cpufreq material queued up for 6.16
in linux-pm.git/linux-next (and in linux-next proper) and are not really
depended on by the rest of the series, but I've decided to include them into
this series because they have been slightly updated since the previous version,
mostly to take review feedback into account (I'm going to queue them up for
6.16 shortly because they don't appear to be objectionable).

The next 2 patches (Energy Model code changes) were reviewed previously, but
they are only needed because of patch [5/7].

Patch [5/7] has not changed much except that some changes made by the previous
version have been dropped from it.  Also its changelog has been updated.  It
causes perf domains to be registered per CPU and in addition to the primary cost
component, which is related to the CPU type, there is a small component
proportional to performance whose role is to help balance the load between CPUs
of the same type.

The expected effect is still that the CPUs of the "low-cost" type will be
preferred so long as there is enough spare capacity on any of them.

Patch [6/7] has been updated to walk all of the cache leaves and look for
the ones with level equal to 3 because the check used in the previous version
does not always work.

The documentation patch, [7/7], is new.

Please refer to the individual patch changelogs for details.

Thanks!

Powered by blists - more mailing lists