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

[Shrikanth Hegde <sshegde@linux.ibm.com>]

Hi Mete, Yury,

On 10/29/26 10:06 PM, Mete Durlu wrote:
> 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.

s390 may not have PARAVIRT=y, but this use case is still a virtualizated system no?
i.e you are observing steal time. By definition of steal time, it is a para-
virtualized system. Though you may be deriving the steal time not using the
paravirt_steal_clock.

Or my understanding here is wrong?

> 
> 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.
> 

We might run into few corner cases quickly with write allowed.
But yes, this is a simpler mechanism not to run anything on few CPUs
in a dynamic way.

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