Message-ID: <22640172.EfDdHjke4D@rjwysocki.net>
Date: Fri, 07 Mar 2025 20:12:11 +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>,
 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:
 [RFC][PATCH v0.3 0/6] cpufreq: intel_pstate: Enable EAS on hybrid platforms
 without SMT - alternative

Hi Everyone,

This is a new take on the "EAS for intel_pstate" work:

https://lore.kernel.org/linux-pm/5861970.DvuYhMxLoT@rjwysocki.net/

with refreshed preparatory patches and a revised energy model design.

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

However, this time perf domains are 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.

This is done to avoid migrating tasks too much between CPUs of the same type,
especially between E-cores, which has been observed in tests of the previous
iteration of this work.

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.

The first two patches in the series rearrange cpufreq checks related to EAS so
that sched_is_eas_possible() doesn't have to access cpufreq internals directly
and patch [3/6] changes those checks to also allow EAS to be used with cpufreq
drivers that implement internal governors (like intel_pstate).

Patches [4-5/6] deal with the Energy Model code.  Patch [4/6] simply rearranges
it so as to allow the next patch to be simpler and patch [5/6] adds a function
that's used in the last patch.

Patch [6/6] is the actual intel_pstate modification which now is significantly
simpler than before because it doesn't need to track the type of each CPU
directly in order to put into the right perf domain.

Please refer to the individual patch changelogs for details.

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

git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
experimental/intel_pstate/eas-take2

or

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

Thanks!

Powered by blists - more mailing lists