All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] sched/cache: Fix a thread aggregation conflict when there is one runnable task
@ 2026-08-10  3:37 Chen Yu
  0 siblings, 0 replies; only message in thread
From: Chen Yu @ 2026-08-10  3:37 UTC (permalink / raw)
  To: Peter Zijlstra, Vincent Guittot, Ingo Molnar, Juri Lelli
  Cc: K Prateek Nayak, Tim Chen, Valentin Schneider, Mel Gorman,
	Steven Rostedt, Dietmar Eggemann, Ben Segall, Yi Lai,
	Zhan Xusheng, chen.yu, linux-kernel, Chen Yu, Zhan Xusheng

Problem Statement:
On systems with SD_ASYM_PACKING set at the PKG domain level (e.g.,
with ITMT enabled), the sched_asym() check in sched_balance_find_src_rq()
prevents pulling a single task from a higher-priority CPU to a
lower-priority CPU. This blocks migrate_llc_task migrations where a task
wants to move to its preferred LLC for cache locality.

For example, CPU 0 (highest priority) has a task preferring LLC3,
but the load balancer on CPU 120 (LLC3) cannot pull it because:
sched_asym(PKG_sd, cpu=0, dst_cpu=120) and nr_running == 1
The task remains stuck in the wrong LLC indefinitely.

Proposal:
Fix this by exempting migrate_llc_task from the sched_asym filter.

The adjacent SD_ASYM_CPUCAPACITY filter was left unchanged. In theory
it should have been handled in the same way. SD_ASYM_CPUCAPACITY is mostly
used in the hybrid CPU situations (e.g. P-core and E-core on some Intel
client CPUs). For those, the difference in CPU performance is pretty
significant and it is unlikely to get as much performance back from cache
co-location vs the CPU capacity. Leave the SD_ASYM_CPUCAPACITY code as is
till a workload and platform show difference otherwise.

Fixes: e4c9a4cb244a ("sched/cache: Add migrate_llc_task migration type for cache-aware balancing")
Reported-by: Yi Lai <yi1.lai@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
---
v1->v2:
   Revise commit log to include the reason why SD_ASYM_CPUCAPACITY is not
   touched. (Zhan Xusheng)
---
 kernel/sched/fair.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d78467ec6ee1..e6e6fa84c9e1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -12986,8 +12986,12 @@ static struct rq *sched_balance_find_src_rq(struct lb_env *env,
 		 *
 		 * If balancing between cores, let lower priority CPUs help
 		 * SMT cores with more than one busy sibling.
+		 *
+		 * For migrate_llc_task, skip this check: cache locality
+		 * outweighs the asym priority.
 		 */
-		if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1)
+		if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1 &&
+		    env->migration_type != migrate_llc_task)
 			continue;
 
 		switch (env->migration_type) {
-- 
2.25.1


^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2026-08-10  3:47 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-10  3:37 [PATCH v2] sched/cache: Fix a thread aggregation conflict when there is one runnable task Chen Yu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.