Re: [PATCH 1/6] sched: decouple PREFERRED_CPU from PARAVIRT in Kconfig.preempt

[Ilya Leoshkevich <iii@linux.ibm.com>]

On 11/2/26 14:00, Shrikanth Hegde wrote:
> Hi.
> 
> 
> On 11/2/26 5:04 PM, Ilya Leoshkevich wrote:
>>
>>
>> On 11/2/26 12:00, Peter Zijlstra wrote:
>>> On Mon, Nov 02, 2026 at 11:16:30AM +0100, Ilya Leoshkevich wrote:
>>>>
>>>>
>>>> On 11/1/26 20:21, Yury Norov wrote:
>>>>> The IBM s390 doesn't enable PARAVIRT config for their hardware
>>>>> virtualized Logical Partitions (LPAR). However, the steal time is
>>>>> accounted for the LPARs, once the config VIRT_CPU_ACCOUNTING_NATIVE
>>>>> is enabled.
>>>>>
>>>>> Preferred cpumask doesn't rely on any feature gated by PARAVIRT 
>>>>> config,
>>>>> and requires it to minimize the configuration space and runtime 
>>>>> overhead,
>>>>> with the lack of non-paravirt user. Now that s390 wants to adopt 
>>>>> preferred
>>>>> cpumask, there's no reason to keep it coupled to paravirt.
>>>>>
>>>>> Make PREFERRED_CPU a user-configurable option, even if 
>>>>> paravirtualization
>>>>> is not enabled, and drop PARAVIRT dependency on the steal governor.
>>>>>
>>>>> Keep the default module selection conditional on PARAVIRT so other SMP
>>>>> configurations can opt in without enabling the governor by default.
>>>>>
>>>>> Link: https://lore.kernel.org/all/4605dad5-aab2-49e3-b919- 
>>>>> bf9897181834@linux.ibm.com/
>>>>> CC: Mete Durlu <meted@linux.ibm.com>
>>>>> Signed-off-by: Yury Norov <ynorov@nvidia.com>
>>>>> ---
>>>>> Can be applied independently from the rest of the series.
>>>>>
>>>>>    drivers/virt/Kconfig   |  8 ++++++--
>>>>>    kernel/Kconfig.preempt | 12 ++++++++++--
>>>>>    2 files changed, 16 insertions(+), 4 deletions(-)
>>>>
>>>> This is really useful to us, since even though s390 is nominally
>>>> paravirtualized, it does not technically benefit from defining
>>>> CONFIG_PARAVIRT.
>>>
>>> And therefore removing PARAVIRT is the only possible solution?
>>>
>>>> Specifically, steal time accounting happens by
>>>> computing a difference between wall time and CPU time, and not by
>>>> explicitly querying the hypervisor.
>>>
>>> Nobody explicitly asks the hypervisor, that would be horrendously slow.
>>>
>>> Something trivial like this should do.
>>>
>>> ---
>>>   arch/Kconfig                           | 9 +++++++++
>>>   arch/powerpc/platforms/pseries/Kconfig | 1 +
>>>   arch/s390/Kconfig                      | 1 +
>>>   drivers/virt/Kconfig                   | 2 +-
>>>   4 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/Kconfig b/arch/Kconfig
>>> index 1163736de1f9..8980054beb52 100644
>>> --- a/arch/Kconfig
>>> +++ b/arch/Kconfig
>>> @@ -1080,6 +1080,15 @@ config HAVE_IRQ_TIME_ACCOUNTING
>>>   config HAVE_PV_STEAL_CLOCK_GEN
>>>       bool
>>> +#
>>> +#  Archs that can account CPUTIME_STEAL; normal route is through 
>>> PARAVIRT which
>>> +#  selects HAVE_PV_STEAL_CLOCK_GEN. Directly selected by s390 and 
>>> PPC-LPAR
>>> +#  which have their own thing and don't go through generic cputime 
>>> accounting.
>>> +#
>>> +config HAVE_CPUTIME_STEAL
>>> +    bool
>>> +    default y if HAVE_PV_STEAL_CLOCK_GEN
>>> +
> 
> Can't PARAVIRT_TIME_ACCOUNTING be the kconfig we can rely upon.
> s390 can add it to the config (similar to HAVE_CPUTIME_STEAL)?
> 
> I guess it is selected currently where the steal time reporting happens.

Looking at update_rq_clock_task(), s390 would still need to provide a
pointless dummy paravirt_steal_clock() implementation in this case.

[...]