linux-kernel - Re: [RFC][PATCH v021 0/9] cpufreq: intel_pstate: Enable EAS on hybrid platforms without SMT

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: <CAJZ5v0hHc5y6LhVRRePr2n2nu=C4XE+Xi-A+D=uxDcsFZDjOJg@mail.gmail.com>
Date: Mon, 27 Jan 2025 14:57:52 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM <linux-pm@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>, 
	Peter Zijlstra <peterz@...radead.org>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.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>, "Zhang, Rui" <rui.zhang@...el.com>
Subject: Re: [RFC][PATCH v021 0/9] cpufreq: intel_pstate: Enable EAS on hybrid
 platforms without SMT

On Sat, Jan 25, 2025 at 12:18 PM Dietmar Eggemann
<dietmar.eggemann@....com> wrote:
>
> On 29/11/2024 16:55, Rafael J. Wysocki wrote:
>
> [...]
>
> > For easier access, the series is available on the experimental/intel_ostate
> > branch in linux-pm.git:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=experimental/intel_pstate
>
> I was wondering how we can test the EAS behaviour (power/perf) on Intel
> hybrid machines.

Thanks a lot for looking into this, much appreciated!

> I have system-wide RAPL 'power/energy-{cores,pkg}' events for power
> (energy) on my i7-13700K (nosmt) so I can run an rt-app workload
> (e.g. 30 5% tasks (0.8ms/16ms)) with:
>
> perf stat -e power/energy-cores/,power/energy-pkg/ --repeat 10 ./rt-app.sh
>
> Plus I can check for negative slack for those rt-app-test tasks (perf)
> and do ftrace-based task placement evaluation.
>
> base:
>
>  Performance counter stats for 'system wide' (10 runs):
>
>        52.67 Joules power/energy-cores/       ( +-  1.24% )
>        85.09 Joules power/energy-pkg/         ( +-  0.83% )
>
>    34.922801 +- 0.000736 seconds time elapsed ( +-  0.00% )
>
>
> EAS:
>
>  Performance counter stats for 'system wide' (10 runs):
>
>        45.55 Joules power/energy-cores/       ( +-  1.07% )
>        75.73 Joules power/energy-pkg/         ( +-  0.67% )
>
>    34.93183 +- 0.00514 seconds time elapsed  ( +-  0.01% )
>
> Do you have another (maybe more sophisticated) test methodology?

Not really more sophisticated, but we cast a wider net, so to speak.

For taks placement testing we use an internal utility that can create
arbitrary synthetic workloads and plot CPU utilization (and other
things) while they are running.  It is kind of similar to rt-app
AFAICS.

We also run various benchmarks and measure energy usage during these
runs, first in order to check if EAS helps in the cases when it is
expected to help, but also to see how it affects the benchmark scores
in general (because we don't want it to make too much of a "negative"
difference for "performance" workloads).

The above results are basically in-line with what we are observing,
but we often see less of a difference in terms of energy usage between
the baseline and EAS enabled.

We also see a lot of task migrations between CPUs in the "low-cost"
PD, mostly in the utilization range where we would expect EAS to make
a difference.  Those migrations are a bit of a concern although they
don't seem to affect benchmark scores.

We think that those migrations are related to the preference of CPUs
with the largest spare capacity, so I'm working on an alternative
approach to enabling EAS that will use per-CPU PDs to see if the
migrations can be reduced this way.