Re: [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection

[Andrea Righi]

Hi Prateek,

On Mon, Apr 20, 2026 at 11:42:23PM +0200, Andrea Righi wrote:
...
> > >> I still have one question: Can first SD_ASYM_CPUCAPACITY_FULL be set at
> > >> a SD_NUMA?
> > >>
> > >> We'll need to deal with overlapping domains then but seems like it could
> > >> be possible with weird cpusets :-(
> > >>
> > >> But in that case, do we even want to search CPUs outside the NUMA in
> > >> select_idle_capacity()? I don't think anything stops this currently but
> > >> I might be wrong.
> > > 
> > > My $0.02 on this.
> > > 
> > > In theory it could happen with unusual topologies or constrained cpusets,
> > > although it should be quite rare. That said, select_idle_capacity() already
> > > operates on the span of sd_asym_cpucapacity, so if that domain crosses NUMA
> > > boundaries, we're already scanning across NUMA today. This patch doesn't
> > > fundamentally alter this behavior.
> > 
> > Ack! I was just thinking loud from the topology standpoint since
> > sd->shared is not designed to handle the overlapping domains like
> > sg->sgc does but we can probably figure some way to make it work.
> > 
> > Using the ring topology example from topology.c:
> > 
> >   0 ----- 1
> >   |       |
> >   |       |
> >   |       |
> >   3 ----- 2
> > 
> > Consider NUMA-1 below gets the SD_ASYM_CPUCAPACITY_FULL flag:
> > 
> >   NUMA-2       0-3             0-3             0-3             0-3
> >    groups:     {0-1,3},{1-3}   {0-2},{0,2-3}   {1-3},{0-1,3}   {0,2-3},{0-2}
> > 
> >   NUMA-1       0-1,3           0-2             1-3             0,2-3
> >    groups:     {0},{1},{3}     {0},{1},{2}     {1},{2},{3}     {0},{2},{3}
> > 
> >   NUMA-0       0               1               2               3
> > 
> > 
> > The "sd->shared" assignments at NUMA-1 will put first, second, and the
> > last domain in the same "shared" range by today's logic since the first
> > CPU in their span is the same although their spans are slightly
> > different.
> > 
> > The third will be standalone since the first CPU of the domain span
> > will be different.
> 
> Yeah, makes sense. I'm wondering if we should attach the shared blob to
> sd_asym_cpucapacity only when asym is a non-overlapping domain, otherwise
> fallback to sd_llc and, in this case, ignore has_idle_cores in
> select_idle_capacity(). This might be not the best in terms of efficiency on
> those exotic topologies, but it'd eliminate the overlap/aliasing risk, while
> still being correct. What do you think?

I slightly changed your patch adding this logic on top, I'll send an updated
patch series, so it's easier to review/comment.

Thanks,
-Andrea