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

[Andrea Righi <arighi@nvidia.com>]

Hi Prateek,

On Fri, Apr 24, 2026 at 04:48:59PM +0530, K Prateek Nayak wrote:
...
> >>>  		if (sd->flags & SD_SHARE_LLC) {
> >>> -			int sd_id = cpumask_first(sched_domain_span(sd));
> >>> -
> >>> -			sd->shared = *per_cpu_ptr(d.sds, sd_id);
> >>> -			atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight);
> >>> -			atomic_inc(&sd->shared->ref);
> >>> +			/*
> >>> +			 * Initialize the sd->shared for SD_SHARE_LLC unless
> >>> +			 * the asym path above already claimed it.
> >>> +			 */
> >>> +			if (!asym_claimed)
> >>> +				init_sched_domain_shared(&d, sd);
> >>
> >> Tbh, if "has_asym" is true, we probabaly don't even need this since the
> >> nr_busy_cpus accounting gets us nothing.
> >>
> >> Might save a little overhead and space on those systems but I would
> >> love to hear if there are any concerns if we just drop the
> >> sd_llc->shared when we detect asym capacities.
> > 
> > Hm... but "has_asym" is global, we may still need LLC-owned shared for symmetric
> > islands and NUMA-overlap cases, no?
> 
> "has_asym" is local to build_sched_domains() right? So it should operate
> per cpuset partition since we call build_sched_domains() for every
> "cpu_map".

Yeah sorry, I meant has_asym is aggregated across the whole cpu_map (not global
machine-wide).

Just to make sure I understand correctly, one CPU in the map can hit the asym
flags while another never claims asym shared and still needs the sd_llc->shared,
but it'd be unused, so why allocate/initialize it, right?

In that case, it'd make sense, but it sounds a bit bug prone, is the extra risk
worth the overhead/space saved? Also, what if we decide to wire nr_busy_cpus
through the asym-capacity path in the future?

Thanks,
-Andrea