Re: [PATCH v2] sched/cache: Honor asym packing over cache aware scheduling on hybrid systems

[Tim Chen]

On Tue, 2026-10-06 at 23:30 +0800, Chen Yu wrote:
> On Mon, Oct 05, 2026 at 11:29:53AM -0700, Tim Chen wrote:
> > Date: Mon,  5 Oct 2026 11:29:53 -0700
> > From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
> > To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>
> > Cc: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Chen Yu <yu.c.chen@xxxxxxxxx>,
> >  Mario Limonciello <mario.limonciello@xxxxxxx>, Vishal Badole
> >  <Vishal.Badole@xxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx,
> >  platform-driver-x86@xxxxxxxxxxxxxxx, K Prateek Nayak
> >  <KPrateek.Nayak@xxxxxxx>, Ricardo Neri <ricardo.neri@xxxxxxxxx>, Kayra
> >  Cizmeci <kayracizmeci@xxxxxxxxx>, stable@xxxxxxxxxxxxxxx, Vincent Guittot
> >  <vincent.guittot@xxxxxxxxxx>, Juri Lelli <juri.lelli@xxxxxxxxxx>, Klaus
> >  Kusche <klaus.kusche@xxxxxxxxxxxxxxx>
> > Subject: [PATCH v2] sched/cache: Honor asym packing over cache aware
> >  scheduling on hybrid systems
> > X-Mailer: git-send-email 2.32.0
> > 
> > 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
> > strategies. Asym packing wants a task to run on the highest priority CPU,
> > whereas cache aware scheduling wants to co-locate the tasks of a process
> > on one LLC regardless of the priority of CPUs in that LLC.
> > 
> > When asym packing tries to migrate task to an idle core that has higher
> > priority than source cpu, let asym packing win.  Moving tasks to a higher
> > performing idle core will buy more performance than cache co-location.
> > 
> > Prioritize asym packing over LLC balancing for regular and active load
> > balancing.
> > 
> > Fixes: 23b2b5ccc45c ("sched/cache: Introduce helper functions to enforce LLC migration policy")
> > Reported-by: Klaus Kusche <klaus.kusche@xxxxxxxxxxxxxxx>
> > Closes: https://lore.kernel.org/lkml/2180ea5a-eb28-4152-8d4d-cd00b0c24b2e@xxxxxxxxxxxxxxx/
> > Suggested-by: Kayra Cizmeci <kayracizmeci@xxxxxxxxx>
> > Tested-by: Klaus Kusche <klaus.kusche@xxxxxxxxxxxxxxx>
> > Tested-by: Ricardo Neri <ricardo.neri@xxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx # 7.2.x
> > Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
> > ---
> > 
> 
> I leveraged AI to test it on top of 7.3.0-rc2 using an emulated hybrid setup on a symmetric
> AMD Ryzen 9 8945HX (Zen 4, 16C/32T, two 32 MB L3):
> 
> By hacking the AMD pstate driver and QOS to limit the L3 cache ways:
> 
>   - LLC0 "big/fast":   CPUs 0-7,16-23, max freq 5.46 GHz, 16 L3 ways (32 MB),
>                        ITMT prefcore ranking 236
>   - LLC1 "little/slow": CPUs 8-15,24-31, max freq 3.29 GHz, 8 L3 ways (16 MB),
>                        ITMT prefcore ranking 100
> 
> Workload: an 8-thread pointer-chase ring (24 MB working set).
> 
> This patch works as expected:
> Before the patch:
>                  cache-aware ON       cache-aware OFF
>   throughput     ~230 M/s             ~530 M/s           (-56.6%)
>   placement      6 of 8 threads       8 threads LLC0
>                  stuck on LLC1
> 
> 
> After the patch:
>                  cache-aware ON       cache-aware OFF
>   throughput     520.7 +- 18.3 M/s    512.9 +- 16.6 M/s   (+1.5%, noise)
>   placement      8 threads LLC0       8 threads LLC0
> 
> 
> Tested-by: Chen Yu <yu.c.chen@xxxxxxxxx>

Thanks for validating the patch.

Tim

> 
> thanks,
> Chenyu