Re: [PATCH v7 02/12] cpumask: Introduce cpu_preferred_mask

[Yury Norov]

On Tue, Jul 14, 2026 at 12:00:51PM +0530, Shrikanth Hegde wrote:
> Hi Yury,

...

> > > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> > > index 88c594c6d7fc..ed02e4431230 100644
> > > --- a/kernel/Kconfig.preempt
> > > +++ b/kernel/Kconfig.preempt
> > > @@ -192,3 +192,6 @@ config SCHED_CLASS_EXT
> > >   	  For more information:
> > >   	    Documentation/scheduler/sched-ext.rst
> > >   	    https://github.com/sched-ext/scx
> > > +
> > > +config PREFERRED_CPU
> > > +	bool
> > 
> > This still should depend on PARAVIRT and SMP. And maybe to enforce it
> > even stronger, your driver should fail to build if PREFERRED_CPU is
> > disabled. Imagine a scenario when someone makes PREFERRED_CPU
> > depending on some other config, but doesn't modify your driver. That
> > way you'll build the STEAL_MONITOR successfully, but because
> > PREFERRED_CPU is off, you'll end up with non-working functionality at
> > best, or corrupted cpu_active_mask at worst.
> > 
> 
> Sorry, i may not understand all the intricacies of kconfigs.
> But, Since driver selects PREFERRED_CPU, and PREFERRED_CPU can't be enabled
> individually, driver again can't depend on PREFERRED_CPU right?
> 
> As per previous discussion, it is probably better that driver selects PREFERRED_CPU.
> Keeping them both independent and selectable brings too many variations.
> No?
> 
> I guess you meant below.
> 
> In kernel/Kconfig.preempt:
> config PREFERRED_CPU
> 	bool
> 	depends on SMP && PARAVIRT
> 
> Driver's Kconfig (this is there already)
> config VIRT_STEAL_GOVERNOR
> 	tristate "Virtual Steal Time Governor"
> 	depends on SMP && PARAVIRT
> 	select PREFERRED_CPU

It's just another precaution. In a hypothetical case of making
preferred CPUs config extended in future, one could keep the steal
governor configuration consistent to avoid this situation:

config PREFERRED_CPU
	depends on SMP && PARAVIRT && NEW_DEPENDENCY
	bool

config VIRT_STEAL_GOVERNOR
	tristate "Virtual Steal Time Governor"
	depends on SMP && PARAVIRT      # NEW_DEPENDENCY dependency missed
	select PREFERRED_CPU            # Selection doesn't happen

In sm_core.c:

  #if !IS_ENABLED(CONFIG_PREFERED_CPU)
  # error "Preferred CPUs is the requirement"
  #endif

As said, it's only precaution for hypothetical case, but it
makes you nice for those working on preferred CPUs in future.

Thanks,
Yury