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

[Andrea Righi <arighi@nvidia.com>]

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

Thanks,
-Andrea