Re: [PATCH v2 2/5] sched/fair: Attach sched_domain_shared to sd_asym_cpucapacity

[Chen, Yu C]

On 5/19/2026 7:47 PM, Peter Zijlstra wrote:
> On Tue, May 19, 2026 at 04:57:11PM +0530, K Prateek Nayak wrote:
> > Hello Peter,
> >
> > On 5/19/2026 2:16 PM, Peter Zijlstra wrote:
> > > Shrikanth noted I had an old version of his SMT ifdeffery patches on, so
> > > I need to rebuild that tree (and the merge) anyway.
> > >
> > > Do you want me to munge this in, or keep it on top as a fixie?
> >
> > Feel free to munge it but if you want to retain some context, here is the
> > full patch with suggestions from Andrea incorporated in:
> >
> >    (Based on top of 5162728eecc2 ("Merge branch 'sched/cache'"))
> >
> > ---
> >  From b0a8ad4b225820c2369f45242517c1c06bac1826 Mon Sep 17 00:00:00 2001
> > From: K Prateek Nayak <kprateek.nayak@xxxxxxx>
> > Date: Tue, 19 May 2026 05:14:23 +0000
> > Subject: [PATCH] sched/topology: Allow multiple domains to claim
> >   sched_domain_shared
> >
> > Recent optimizations of sd->shared assignment moved to allocating a
> > single instance of per-CPU sched_domain_shared objects per s_data.
> >
> > Recent optimizations to select_idle_capacity() moved the sd->shared
> > assignments to "sd_asym" domain when ASYM_CPUCAPACITY is detected but
> > cache-aware scheduling mandates the presence of "sd_llc_shared" to
> > compute and cache per-LLC statistics.
> >
> > Use an "alloc_flags" union in sched_domain_shared to claim a
> > sched_domain_shared object per sched_domain. Allocation starts searching
> > for an available / matching sched_domain_shared instance from the first
> > CPU of sched_domain_span(sd) (sd can be sd_llc, or sd_asym). If the
> > shared object is claimed by another domain, the instance corresponding
> > to next CPU in the domain span is explored until a matching / available
> > instance is found.
> >
> > In case of a single CPU in sched_domain_span(), the domain will be
> > degenerated and a temporary overlap of ->shared objects across different
> > domains is acceptable.
> >
> > "alloc_flags" forms a union with "nr_idle_scan" and the stale flags are
> > left as is when the sd->shared is published. The expectation is for the
> > first load balancing instance to correct the value just like the current
> > behavior, except the initial value is no longer 0.
> >
> > Originally-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Tested-by: Andrea Righi <arighi@xxxxxxxxxx>
> > Signed-off-by: K Prateek Nayak <kprateek.nayak@xxxxxxx>
>
> Since you wrote a nice changelog, I stuck it on top. Pushed out a fresh
> queue:sched/core with updated patches from Shrikanth and this on top.
>
> Seems to build and boot in a random vm, so must be good ;-)
>
> I'll push into -tip in a day or so, provided nothing goes boom in the
> meantime.

Cache-aware scheduling works as expected on top of latest sched/core.
Performance gains were observed via hackbench. Tests were also
conducted on Alder Lake, P-core with SMT-enabled and E-cores without SMT,
yet no notable discrepancies were found, so only paste the server data
here. In future we may need to apply cache-aware scheduling to hybrid CPUs.
For now, the current version should be OK, unless LKP 0day spots anything
unusual later.

=========================================
Hackbench comparison
BASE: baseline
TEST: sched_cache
=========================================
MODE     G  FD |         BASE(s) |         TEST(s) |   DIFF% | RESULT
------- -- ----+-----------------+-----------------+---------+----------
threads  1  10 |    108.020/0.3% |     65.355/2.1% |  39.50% | IMPROVED
threads  1   2 |     17.246/2.6% |      9.761/1.9% |  43.40% | IMPROVED
threads  1  20 |    253.990/1.7% |    245.875/3.0% |   3.20% | IMPROVED
threads  1   4 |     40.849/5.2% |     24.030/0.0% |  41.17% | IMPROVED
threads  1   6 |     61.659/1.0% |     38.852/3.5% |  36.99% | IMPROVED
threads  1   8 |     86.121/0.5% |     51.900/1.7% |  39.74% | IMPROVED
threads  2  10 |    121.315/0.7% |   115.118/11.1% |   5.11% | IMPROVED
threads  2   2 |     17.647/5.6% |      9.858/0.4% |  44.14% | IMPROVED
threads  2  20 |    333.429/5.4% |    320.477/5.4% |   3.88% | IMPROVED
threads  2   4 |     43.612/1.0% |     26.275/1.9% |  39.75% | IMPROVED
threads  2   6 |     69.413/0.9% |     41.151/0.8% |  40.72% | IMPROVED
threads  2   8 |     95.811/0.1% |     52.816/1.7% |  44.87% | IMPROVED
threads  4  10 |    148.215/1.3% |    146.949/3.2% |   0.85% | IMPROVED
threads  4   2 |     18.987/0.9% |     10.065/1.8% |  46.99% | IMPROVED
threads  4  20 |    832.352/2.0% |    768.323/1.7% |   7.69% | IMPROVED
threads  4   4 |     47.413/0.9% |     24.087/6.2% |  49.20% | IMPROVED
threads  4   6 |     75.117/0.2% |     76.142/0.3% |  -1.36% | REGRESSED
threads  4   8 |    110.599/1.0% |    108.190/2.7% |   2.18% | IMPROVED