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

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

On 30/10/2026 15:53, Shrikanth Hegde wrote:
> 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?

Yes, it is virtualized.

> 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?
> 
So you propose s390 to enable CONFIG_PARAVIRT *just because* s390
fits the "paravirtualized system" definition, even if s390 would not
utilize any functionality comes with the config option? (even worse
it comes with deadcode...)

That sounds a bit wrong to me, I would really like to avoid
enabling a config option just because it's name suggests that
it is related to our platform.

Yury already sent the patch series he mentioned. I suppose we should
keep discussing this there.

Thank you!
-Mete