mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Klaus Kusche <klaus.kusche@computerix.info>,
	Chen Yu <yu.c.chen@intel.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>,
	"Badole, Vishal"	 <Vishal.Badole@amd.com>,
	Peter Zijlstra <peterz@infradead.org>,
	 linux-kernel@vger.kernel.org,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	platform-driver-x86@vger.kernel.org,
	K Prateek Nayak	 <KPrateek.Nayak@amd.com>,
	ricardo.neri@intel.com
Subject: Re: Cache-aware scheduling does not work well with amd big/little cores
Date: Wed, 23 Sep 2026 16:47:58 -0700	[thread overview]
Message-ID: <7b83cf0cd1704b552978af88d7de9c57970c23a1.camel@linux.intel.com> (raw)
In-Reply-To: <8aea0f25-0317-42ac-b59f-1a008c6eb106@computerix.info>

On Wed, 2026-09-16 at 16:52 +0200, Klaus Kusche wrote:
> I don't know what your last patch does (does it dynamically disable 
> cache aware scheduling on big/little CPU's?),
> but it makes my two build tests running at almost the same speed
> on a kernel with cache aware scheduling
> compared to a kernel without cache aware scheduling, 
> which means it is rougly 2 % faster 
> than earlier cache aware scheduling kernels.
> 
> Just by looking at the core bar graph,
> I also didn't see any obviously misplaced processes.

Hi Klaus,

I wonder if you can try this alternate patch to Chen Yu's.
This patch does not require turning off cache aware scheduling
entirely as in the previous patch when using the asym packing
mechanism to prioritize big core.

Hopefully it will have a similar effect to restore performance
on your tests.

Thanks.

Tim

From 7bad1c19317e08d398fa36d66940867110bdd037 Mon Sep 17 00:00:00 2001
From: Tim Chen <tim.c.chen@linux.intel.com>
Date: Wed, 23 Sep 2026 14:28:40 -0700
Subject: [PATCH] sched/cache: Honor asym packing over cache aware scheduling
 on hybrid system

A regression was reported on an AMD Ryzen AI HX 370 running a cache
intensive Clang full-LTO link. The little cores run at a much lower
frequency (3.3 GHz vs 5.1 GHz) and have only half of the L3 cache
(8 MB vs 16 MB), so pinning such a task to the little-core LLC hurts
twice, and full-LTO builds slow down dramatically compared to
pre-cache-aware-scheduling kernels.

Asym packing and cache aware scheduling express conflicting placement
strategy. Asym packing wants a task to run on the highest priority
CPU, whereas CAS wants to co-locate the tasks of a process on one LLC
regardless of the priority of CPUs in that LLC. When asym packing
is turned on, it is trying to migrate task to an empty core that has
higher priority than source cpu, let asym packing win.

Reported-by: Klaus Kusche <klaus.kusche@computerix.info>
Closes: https://lore.kernel.org/lkml/2180ea5a-eb28-4152-8d4d-cd00b0c24b2e@computerix.info/
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
---
 kernel/sched/fair.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f265de8721db..89eed4fbc4e2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -10823,6 +10823,8 @@ static inline bool task_misfits_asym_cpu(struct lb_env *env, struct task_struct
 	return false;
 }
 
+static inline bool sched_asym(struct sched_domain *sd, int dst_cpu, int src_cpu);
+
 /*
  * Check if task p can migrate from source LLC to
  * destination LLC in terms of cache aware load balance.
@@ -10847,6 +10849,10 @@ static enum llc_mig can_migrate_llc_task(struct lb_env *env,
 	if (cpu < 0 || cpus_share_cache(src_cpu, dst_cpu))
 		return mig_unrestricted;
 
+	/* Prioritize asym packing over cache awareness */
+	if (sched_asym(env->sd, dst_cpu, src_cpu))
+		return mig_unrestricted;
+
 	/* skip cache aware load balance for too many threads */
 	if (invalid_llc_nr(grp, p, dst_cpu) ||
 	    exceed_llc_capacity(grp, dst_cpu)) {
@@ -12043,6 +12049,15 @@ static inline bool llc_balance(struct lb_env *env, struct sg_lb_stats *sgs,
 	    sgs->group_misfit_task_load)
 		return false;
 
+	/*
+	 * On asym packing domains, if the destination CPU
+	 * has higher priority than all CPUs in the source group,
+	 * prioritize asym packing.
+	 */ 
+	if ((env->sd->flags & SD_ASYM_PACKING) &&
+	    sgs->group_asym_packing)
+		return false;
+
 	/*
 	 * Skip cache aware tagging if nr_balanced_failed is sufficiently high.
 	 * Threshold of cache_nice_tries is set to 1 higher than nr_balance_failed
@@ -13458,12 +13473,12 @@ static int need_active_balance(struct lb_env *env)
 {
 	struct sched_domain *sd = env->sd;
 
-	if (alb_break_llc(env))
-		return 0;
-
 	if (asym_active_balance(env))
 		return 1;
 
+	if (alb_break_llc(env))
+		return 0;
+
 	if (imbalanced_active_balance(env))
 		return 1;
 
-- 
2.32.0



      reply	other threads:[~2026-09-23 23:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-29 15:42 Klaus Kusche
2026-08-31  1:53 ` Mario Limonciello
2026-08-31  2:08   ` Chen, Yu C
2026-08-31 11:24     ` Klaus Kusche
2026-08-31 17:29       ` Tim Chen
2026-08-31 18:49         ` Klaus Kusche
2026-08-31 18:53           ` Mario Limonciello
2026-09-05 15:40         ` Klaus Kusche
2026-09-08 21:54           ` Tim Chen
2026-09-09  8:59             ` Klaus Kusche
2026-09-09 13:19               ` Mario Limonciello
2026-09-09 19:51                 ` Tim Chen
2026-09-10  1:29                   ` Chen, Yu C
2026-09-14 10:27                     ` Klaus Kusche
2026-09-14 13:13                       ` Chen Yu
2026-09-16 14:52                         ` Klaus Kusche
2026-09-23 23:47                           ` Tim Chen [this message]

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=7b83cf0cd1704b552978af88d7de9c57970c23a1.camel@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=KPrateek.Nayak@amd.com \
    --cc=Vishal.Badole@amd.com \
    --cc=klaus.kusche@computerix.info \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=peterz@infradead.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=ricardo.neri@intel.com \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /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

all inboxes | Powered by JetHome®