Message-ID: <20250409053446.23367-1-kprateek.nayak@amd.com>
Date: Wed, 9 Apr 2025 05:34:42 +0000
From: K Prateek Nayak <kprateek.nayak@....com>
To: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
	<vincent.guittot@...aro.org>, "Gautham R. Shenoy" <gautham.shenoy@....com>,
	Mario Limonciello <mario.limonciello@....com>, "Rafael J. Wysocki"
	<rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC: Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt
	<rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman
	<mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, Waiman Long
	<llong@...hat.com>, Swapnil Sapkal <swapnil.sapkal@....com>, "Dhananjay
 Ugwekar" <Dhananjay.Ugwekar@....com>, Huang Rui <ray.huang@....com>, "Perry
 Yuan" <perry.yuan@....com>, K Prateek Nayak <kprateek.nayak@....com>
Subject: [PATCH v2 0/4] sched/fair: Dynamic asym priority support

A subset of AMD Processors which support Preferred Core rankings can
have these rankings change at runtime to bias the load balancing towards
CPUs with higher frequency / larger cache.

In the current implementation, the CPU with the highest asym priority -
"asym_prefer_cpu" is cached in the sched_group struct when building the
sched domain hierarchy.

Previous approach in [1] to uncache the "asym_prefer_cpu" and compute it
during load balancing was not popular as it not only lost the benefits
of caching but also added more overhead in update_sg_lb_stats().

At OSPM'25, Vincent suggested retaining "asym_prefer_cpu" but updating
it dynamically when the asym priority changes without needing to
rebuild the entire sched domain hierarchy.

Introduce sched_update_asym_prefer_cpu() which traverses the local
hierarchy on priority change and recomputes the "asym_prefer_cpu". Since
sched_group for !SD_OVERLAP domains are shared by all the CPUs in
sched_group_span(sg) (see get_group() in kernel/sched/topology.c),
updating the "asym_prefer_cpu" in the groups of the local hierarchy
ensures all the CPUs in the group see the updated value.

Groups of SD_OVERLAP domains can be supported too but this involves
moving "asym_prefer_cpu" to "sg->sgc" which adds another level of
indirection. Since there isn't a use case currently where both
SD_OVERLAP and SD_ASYM_PACKING is set for the same sched domain, v2
keeps things simple only extends dynamic updates to groups of
!SD_OVERLAP domains. If this future looking enablement is required,
please do let me know.

Printing the "asym_prefer_cpu" for the local group in debugfs has not
only proved useful to debug this series but has also helped uncover
other unrelated issues like [2] which is why I've retained it for
inclusion.

This series is based on:

  git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core

at commit 6432e163ba1b ("sched/isolation: Make use of more than one
housekeeping cpu")

[1] https://lore.kernel.org/lkml/20241211185552.4553-9-kprateek.nayak@amd.com/
[2] https://lore.kernel.org/lkml/20250409030004.23008-1-kprateek.nayak@amd.com/
---
Changelog:

v1..v2:

o New approach that introduces sched_update_asym_prefer_cpu() to update
  the "asym_prefer_cpu" dynamically on ranking change without rebuilding
  the sched domain hierarchy.
---
K Prateek Nayak (4):
  sched/fair: Use READ_ONCE() to read sg->asym_prefer_cpu
  sched/topology: Introduce sched_update_asym_prefer_cpu()
  cpufreq/amd-pstate: Update asym_prefer_cpu when core rankings change
  sched/debug: Print the local group's asym_prefer_cpu

 drivers/cpufreq/amd-pstate.c   |  4 ++-
 include/linux/sched/topology.h |  6 ++++
 kernel/sched/debug.c           |  4 +++
 kernel/sched/fair.c            |  5 +--
 kernel/sched/topology.c        | 58 ++++++++++++++++++++++++++++++++++
 5 files changed, 74 insertions(+), 3 deletions(-)


base-commit: 6432e163ba1b7d80b5876792ce53e511f041ab91
-- 
2.34.1

Powered by blists - more mailing lists