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

["Chen, Yu C" <yu.c.chen@intel.com>]

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@amd.com>
>> 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@infradead.org>
>> Tested-by: Andrea Righi <arighi@nvidia.com>
>> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> 
> 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