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

[Ilya Leoshkevich]

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@xxxxxxxxxxxxx/
> > > > > CC: Mete Durlu <meted@xxxxxxxxxxxxx>
> > > > > Signed-off-by: Yury Norov <ynorov@xxxxxxxxxx>
> > > > > ---
> > > > > 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.

[...]