Re: [PATCH v14 04/13] cpumask: Introduce cpu_preferred_mask

[Yury Norov]

On Thu, Oct 29, 2026 at 02:32:08PM +0100, Mete Durlu wrote:
> On 28/09/2026 07:37, Shrikanth Hegde wrote:
> > Provide the preferred CPU infrastructure. Define get/set macros
> > which could be used to get/set CPU state as preferred.
> > 
> > CONFIG_PREFERRED_CPU will be selected by the driver which handles
> > steal time values. It is going to set/clear preferred CPU state.
> > This driver will be called steal_governor and it is introduced in
> > subsequent patches. It periodically computes the steal ratio and
> > decides on preferred CPU state.
> > 
> > A CPU is set to preferred when it becomes active. Later it may be
> > marked as non-preferred depending on steal ratio by the steal_governor.
> > 
> > Always maintain design construct of preferred is subset of active.
> > i.e. preferred ⊆ active ⊆ online ⊆ present ⊆ possible
> > 
> > With CONFIG_PREFERRED_CPU=n, ensure set_cpu_preferred is a nop and get
> > method returns the active state in that case.
> > 
> > Signed-off-by: Shrikanth Hegde <sshegde@xxxxxxxxxxxxx>
> > ---
> >   include/linux/cpumask.h | 24 ++++++++++++++++++++++++
> >   kernel/Kconfig.preempt  |  4 ++++
> >   kernel/cpu.c            |  6 ++++++
> >   kernel/sched/core.c     |  5 +++++
> >   4 files changed, 39 insertions(+)
> 
> [..snip..]
> 
> >   #define cpu_is_offline(cpu)	unlikely(!cpu_online(cpu))
> > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> > index 985aea617cfe..edc067a0c422 100644
> > --- a/kernel/Kconfig.preempt
> > +++ b/kernel/Kconfig.preempt
> > @@ -194,3 +194,7 @@ config SCHED_CLASS_EXT
> >   	  For more information:
> >   	    Documentation/scheduler/sched-ext.rst
> >   	    https://github.com/sched-ext/scx
> > +
> > +config PREFERRED_CPU
> > +	bool
> > +	depends on SMP && PARAVIRT
> FWICT, PREFERRED_CPU mechanism can work perfectly fine without PARAVIRT
> selected. It would be annoying to enable it and implement a dummy
> paravirt_steal_clock() just for that.
> 
> Shrikanth, would it be possible to drop that dependency?

Do you have a non-paravirt case in mind? 

I'm actually about to submit an RFC that drops the PARAVIRT dependency
and provides write access to the preferred mask. But I want to make
sure that we need it, and we've got no reasonable mechanism to put
unneeded CPUs on idle already.

Simply relaxing the PARAVIRT dependency without a solid use case would
bloat configuration space for nothing. If you've got such a case in
mind, the rest is trivial.

Thanks,
Yury