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

[Mete Durlu <meted@linux.ibm.com>]

On 29/10/2026 17:28, Yury Norov wrote:
> 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@linux.ibm.com>
>>> ---
>>>    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?

s390 LPARs are exactly that. s390 does not select PARAVIRT by default
but enabling PREFERRED_CPU is strongly considered.

I removed the PARAVIRT dependency and gave the whole thing a quick
spin. Builds and functions w/o any issues on s390!
> 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.

You can mention s390 LPARs as valid case on your RFC if need be.
Thank you!