Re: Cache-aware scheduling does not work well with amd big/little cores

[Tim Chen]

On Sat, 2026-09-05 at 17:40 +0200, Klaus Kusche wrote:
> Hello,
> 
> On 31/08/2026 19:29, Tim Chen wrote:
> > On Mon, 2026-08-31 at 13:24 +0200, Klaus Kusche wrote:
> > > Hello,
> > > 
> > > both patches in combination seem to have the desired effect.
> > > 
> > > But I just look at a bar graph showing the current load
> > > of each core. 
> > > The graph suggests that long-running CPU-intensive processes 
> > > migrate to fast cores when fast cores become available.
> > > And I have the impression that LTO compilations
> > > finish significantly faster now.
> > > 
> > > I don't have exact numbers or benchmarks.
> > 
> > Thanks for testing the fix.
> > 
> > If you just apply https://lore.kernel.org/lkml/20260825174112.2580942-1-tim.c.chen@xxxxxxxxxxxxxxx/,
> > with default aggr_tolerance, what numbers do you see?
> > 
> > That will be helpful for further tuning.  Thanks.
> > 
> > Tim 
> 
> I did some quick testing (no perfect benchmark environment,
> just checking runtime and CPU consumption with "time").
> 
> I timed a kernel build (-j 24 and full lto, my own .config)
> and an application build (also with a lot of parallelism)
> with three different kernels:
> 
> a) Cache aware scheduling completely configured off
> 
> b) Cache aware scheduling turned on, but without patch
> 
> c) Cache aware scheduling turned on, with patch
> 
> Big/little scheduling was always on, 
> Mario's patch was always applied
> (without it, results are significantly worse,

Sorry, I am a bit confused.  You mentioned later the result for (b)
and (c) are about the same with or without the patch
exposing debugfs (commit c1e7fe5e75ed11fa85368e5a186472afd3858f3a
Mario mentioned in another mail).  
But here you say the result is much worse without Mario's patch.
Is Mario's patch the one above or some other patch? 

> because I use kernels without debugfs,
> so big/little scheduling is off without the patch).
> 
> Results:
> 
> There is no significant difference between b) and c) 
> (<= 1 % wallclock time)

Yes, I don't expect difference between (b) and (c).  My
understanding is the patch in question is to only
expose the default cache aware parameters via debugfs
but don't acutally change them.

> Sometimes b) is better, sometimes c) is better,
> I'd say the differences are below the accuracy of my tests.
> 
> But a) was reproducibly better than b) and c)
> w.r.t. wallclock time: 2-2.6 %
> It was also very slightly better w.r.t. total kernel CPU seconds.
> The results w.r.t. total usermode CPU seconds varied too much.
> (I always ran the application build twice,
> and for all a), b) and c), the second run consumed
> significantly more usermode CPU seconds,
> but took a little less wallclock time - I don't know why).

Will have to look around to see if we have some similar CPUs
as HX-370.  My understanding is that the 4 big cores are in
one L3 and the 8 small cores are in another L3.

BTW, we have also found two issues with the active load balance
paths for CAS that need fixes.  You may want to add those patches
and see if they are helpful to improve things.

Active load balance fixes:
https://lore.kernel.org/lkml/20260903020656.3793626-1-wanglu.priv@xxxxxxxxx/
https://lore.kernel.org/lkml/2b0a35122ee615c6fa51076e5d79330e633755ac.camel@xxxxxxxxxxxxxxx/


Tim

> 
> So in short, at least for the two build benchmarks I made,
> and with respect to the wallclock time they took, AMD Ryzen HX 370 
> does slightly better completely *without* cache aware scheduling,
> but cache aware scheduling looses less than 3 %,
> both with and without the patch.
> 
> The big difference I observed when 7.2 came out 
> was perhaps due to the fact
> that the older version of Mario's patch I had
> did not apply correctly or did not work as expected with 7.2.
> 
> Greetings