public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Lukasz Luba <lukasz.luba@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
	Pierre Gondois <pierre.gondois@arm.com>,
	Christian Loehle <christian.loehle@arm.com>
Subject: [RFT][PATCH v1 0/8] cpufreq: intel_pstate: Enable EAS on hybrid platforms without SMT
Date: Wed, 16 Apr 2025 19:44:43 +0200	[thread overview]
Message-ID: <3344336.aeNJFYEL58@rjwysocki.net> (raw)

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!




             reply	other threads:[~2025-04-16 18:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 17:44 Rafael J. Wysocki [this message]
2025-04-16 17:48 ` [RFT][PATCH v1 1/8] cpufreq/sched: schedutil: Add helper for governor checks Rafael J. Wysocki
2025-04-17 12:23   ` Christian Loehle
2025-04-16 17:59 ` [RFT][PATCH v1 2/8] cpufreq/sched: Move cpufreq-specific EAS checks to cpufreq Rafael J. Wysocki
2025-04-17 12:28   ` Christian Loehle
2025-04-16 18:01 ` [RFT][PATCH v1 3/8] cpufreq/sched: Allow .setpolicy() cpufreq drivers to enable EAS Rafael J. Wysocki
2025-04-17 12:19   ` Christian Loehle
2025-04-17 13:01     ` Rafael J. Wysocki
2025-04-17 13:03       ` Christian Loehle
2025-04-16 18:04 ` [RFT][PATCH v1 4/8] PM: EM: Move CPU capacity check to em_adjust_new_capacity() Rafael J. Wysocki
2025-04-16 18:06 ` [RFT][PATCH v1 5/8] PM: EM: Introduce em_adjust_cpu_capacity() Rafael J. Wysocki
2025-04-27 14:01   ` Dietmar Eggemann
2025-04-30 19:23     ` Rafael J. Wysocki
2025-05-01 12:30       ` Dietmar Eggemann
2025-05-06 19:46         ` Rafael J. Wysocki
2025-04-16 18:09 ` [RFT][PATCH v1 6/8] cpufreq: intel_pstate: EAS support for hybrid platforms Rafael J. Wysocki
2025-04-16 18:10 ` [RFT][PATCH v1 7/8] cpufreq: intel_pstate: Align perf domains with L2 cache Rafael J. Wysocki
2025-04-17 12:42   ` Christian Loehle
2025-04-27 16:23   ` Dietmar Eggemann
2025-04-30 19:29     ` Rafael J. Wysocki
2025-05-01 12:30       ` Dietmar Eggemann
2025-04-16 18:12 ` [RFT][PATCH v1 8/8] cpufreq: intel_pstate: EAS: Increase cost for CPUs using L3 cache Rafael J. Wysocki
2025-04-25 21:32   ` Christian Loehle
2025-04-25 21:39     ` Rafael J. Wysocki
2025-04-18  9:58 ` [RFT][PATCH v1 0/8] cpufreq: intel_pstate: Enable EAS on hybrid platforms without SMT Christian Loehle
2025-04-18 19:52   ` Rafael J. Wysocki
2025-05-12 13:23 ` [PATCH v1] cpufreq: Drop policy locking from cpufreq_policy_is_good_for_eas() Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3344336.aeNJFYEL58@rjwysocki.net \
    --to=rjw@rjwysocki.net \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=pierre.gondois@arm.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox