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

[Shrikanth Hegde]

On 10/9/26 8:42 PM, Andrea Righi wrote:
> On Thu, Oct 08, 2026 at 09:14:49PM +0530, Shrikanth Hegde wrote:
> ...
> > > > > That might let us preserve the general preference for fully idle SMT cores while
> > > > > searching in this order: fully idle preferred cores, idle SMT threads on
> > > > > preferred cores, then non-preferred cores. This current patch series seems to
> > > > > drop the first distinction, allowing a partially idle preferred core to win even
> > > > > when another preferred core is fully idle.
> > > > >
> > > > > This would need to coexist with the steal governor's stronger use of
> > > > > cpu_preferred_mask, so I'm suggesting it as a potential direction to explore
> > > > > rather than a drop-in replacement.
> > >
> > > I think this makes a lot of sense. An approach to first fill preferred
> > > CPUs before spilling to the non-preferred cores until contention
> > > forces the evacuation of non-prefered CPUs.
> >
> > Well, when we see steal time, it usually means there is high contention and
> > we are using more vCPUs at this moment than possible.
> > So we mark them as non-preferred. Note that they are idle cpus. But non-preferred.
> >
> > That means preferred CPUs may have more than 1 task. If we spill over if there
> > is idle non-preferred CPUs, we will be back to square one. No?
>
> I agree that CPUs excluded by the steal governor should remain avoided even when
> all preferred CPUs are busy.
>
> I'm wondering if we should have two levels: cpu_preferred_mask acting as a hard
> affinity constraint and an entitlement-based soft affinity within that mask? The

That not what entitlement usually means. At least not PowerVM. when one creates VM,
they assign VP=Virtual Cores and EC=Entitled Cores. and Hypervisor ensure at least EC
worth of cores are always assigned to that VM. There is no need of priority within that
entitlement.

> soft affinity would prefer high-entitlement CPUs: first fully idle cores, then
> idle SMT siblings. Once those CPUs are busy, tasks could spill onto

I think when one has high steal time and hence reduced preferred CPUs, there will
likely be no fully idle cores within preferred CPUs.

Note that current logic takes out last set of CPUs and find_new_ilb iterates from
the beginning. So if there is idle core within the preferred CPUs, it will be chosen.

> lower-entitlement CPUs still inside cpu_preferred_mask, again preferring fully
> idle cores over idle SMT siblings. If all CPUs inside cpu_preferred_mask are
> busy, tasks would queue there. The soft affinity would never override the
> governor's restriction by spilling onto CPUs it excluded due to contention.
As we were discussing, as long as threads don't end up on non-preferred CPUs,
we might be okay. With the above, find_new_ilb will becomes very complex IMHO
and I am not sure if it is worth it.

likely what we need is,
- Fully idle preferred Core.
- idle preferred CPU.
- any idle CPU.