Message-ID: <12d630f9-e917-4b9f-ab27-621886c13334@arm.com>
Date: Fri, 18 Apr 2025 10:58:08 +0100
From: Christian Loehle <christian.loehle@....com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
 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>
Subject: Re: [RFT][PATCH v1 0/8] cpufreq: intel_pstate: Enable EAS on hybrid
 platforms without SMT

On 4/16/25 18:44, Rafael J. Wysocki wrote:
> Hi Everyone,
> 
> This is a new version of
> 
> https://lore.kernel.org/linux-pm/22640172.EfDdHjke4D@rjwysocki.net/
> 
> which is not regarded as RFC any more.  It appears to be better than
> 
> https://lore.kernel.org/linux-pm/5861970.DvuYhMxLoT@rjwysocki.net/
> 
> but still requires more testing, so I'd appreciate any help here.
> 
> 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 3 patches have been updated since v0.3 and they now depend on the new
> cpufreq material in linux-next.
> 
> The next 2 patches (Energy Model code changes) have been reviewed in the
> meantime, but they are only needed for the last 3 patches.
> 
> Patch [6/8] is essentially the same as before.  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.
> 
> 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
> 
> https://lore.kernel.org/linux-pm/5861970.DvuYhMxLoT@rjwysocki.net/
> 
> 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 last 2 patches are new.
> 
> Patch [7/8] looks at the cache topology to avoid creating per-CPU perf domains
> for CPUs sharing an L2 cache.  Typically, on the chips that will be affected
> by this patch, CPUs sharing an L2 cache also share a voltage regulator and a
> clock, so they technically belong to the same OPP domain and they will be put
> into a shared perf domain after this patch.
> 
> Patch [8/8] makes CPUs sharing the L3 cache look slightly more expensive to
> cause the scheduler to prefer placing tasks on CPUs that don't use the L3,
> which in some cases should allow all of the CPUs sharing the L3 to stay in
> idle states and the energy usage should be reduced.
> 
> Please refer to the individual patch changelogs for details.
> 
> Since patches [7-8/8] also apply on top of the v0.3, I have created a git branch at
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
> experimental/intel_pstate/eas-take2-extended
> 
> or
> 
> https://web.git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=experimental/intel_pstate/eas-take2-extended
> 
> to allow the difference they make with respect to the v0.3 to be seen (if any).
> 
> Later, I'm going to put this series as a whole into a new git branch on top of
> the mainline and the cpufreq material queued up for 6.16.
> 
> Thanks!
> 

Similar to the v0.3 tests done here:
https://lore.kernel.org/linux-pm/6ab0531a-d6d8-46ac-9afc-23cf87f37905@arm.com/
here are the results for the same raptor lake nosmt machine (now with
4 e-cores + 4 e-cores and 8x1 p-core PDs, 10 PDs in total).

Firefox YouTube 4K video playback:
EAS:
684.504 +-19.167841239372198
CAS:
929.83 +-50.41498564690636
(-26.3844% energy used with EAS)
(cf. -43.1% energy used with EAS v0.3)
(cf. -24.2% energy used with EAS v0.2)

Firefox Web Aquarium 500 fish.
EAS:
540.192 +-14.294833410089904
CAS:
712.896 +-16.821304745272684
(-24.2257% energy used with EAS)
(cf. -35.6% energy used with EAS v0.3)

Seems the per-CPU PD worked better, at least for this machine, which arguably
isn't the main target of the series.
Feel free to add
Tested-by: Christian Loehle <christian.loehle@....com>
to patches 1 to 7 (the tested system isn't affected by 8/8).

Powered by blists - more mailing lists