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

[Peter Zijlstra]

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.