Re: [PATCH RFC 0/2] sched: Introduce idle SMT priority for asymmetric capacity systems

[Shrikanth Hegde]

Hi Mete.

On 10/20/26 2:43 PM, Mete Durlu wrote:
> Hi again,
>
> > > > What you describe really fit into the prefered core that Shrikanth
> > > > Hegde has developped
> > >
> > > I agree, but Shrikanth's solution can not bring some of the
> > > behavior changes required. cpu_preferred_mask can help
> > > direct task placement away from low capacity cores but idle
> > > core first approach still places tasks to fully idle low
> > > capacity cores. This patches proposal tries to move tasks
> > > first to the idle SMT siblings.
> >
> > We have compute capacity to decide which CPU is better than others.
> > The capacity of SMT CPU has also been somewhat random, but we should
> > find a way to fix this instead of adding a threshold to decide whether
> > to pack or spread tasks onto idle cores. With correct per CPU
> > capacity, we can easily decide if an idle low core is better or not
> > than the sibling of an already busy high core.
> After thinking about this a bit more, I have decided to work
> on a different approach rather than trying to integrate
> into Shrikanth's vCPU backoff or trying to expand this series.
>
> I'll come back with another series after I become more familiar
> with how the SMT capacities are calculated and incorporated in
> the decision making process. My gut says the real challenge is
> going to be finding a way to benefit all architectures that
> configure asymmetric capacities but I'll give it a shot.

I think you can split this issues into two.

1. Does choosing idle vertical high SMT CPU is always better than
   an idle vertical low SMT core. This isn't related to any system pressure
   or steal time. If yes, you may need something like ASYM_PACKING, or
   select_idle_capacity etc.

2. If you want to avoid vertical low cores when under high steal time, then
   using steal governor is probably right direction.
   We could add arch specific hooks if current logic doesn't achieve it.
   But this is only under HW pressure, not always.
 
> Thanks for the valuable comments and guidance.
> -Mete