Hi Emanuele, On Tuesday, 10 October 2023 15:02:07 CEST Emanuele Rocca wrote: > On 2023-10-10 01:54, Diederik de Haas wrote: > > On Tuesday, 10 October 2023 12:10:07 CEST Emanuele Rocca wrote: > > > CONFIG_PREEMPT_DYNAMIC is set to 'y' by default on amd64 > > > due to HAVE_PREEMPT_DYNAMIC_CALL being 'y' > > > > > > arm64 does not have PREEMPT_DYNAMIC_CALL, this is why PREEMPT_DYNAMIC is > > > not set by default there.
"by default" would be my emphasis
$ grep -A6 "config PREEMPT_DYNAMIC" kernel/Kconfig.preempt
config PREEMPT_DYNAMIC
bool "Preemption behaviour defined on boot"
depends on HAVE_PREEMPT_DYNAMIC && !PREEMPT_RT
select JUMP_LABEL if HAVE_PREEMPT_DYNAMIC_KEY
select PREEMPT_BUILD
default y if HAVE_PREEMPT_DYNAMIC_CALL
help
So HAVE_PREEMPT_DYNAMIC is the requirement afaict.
As you said in your other mail, that can be done by _CALL, but also by _KEY.
$ grep -rnE "(select|depends on) HAVE_PREEMPT_DYNAMIC_(KEY|CALL)"
arch/arm64/Kconfig:224: select HAVE_PREEMPT_DYNAMIC_KEY
arch/riscv/Kconfig:137: select HAVE_PREEMPT_DYNAMIC_KEY if !XIP_KERNEL
arch/x86/Kconfig:273: select HAVE_PREEMPT_DYNAMIC_CALL
On arm64 it's selected if ARM64 is set and on risv when RISCV is set.
> Right, but HAVE_PREEMPT_DYNAMIC_CALL is not a config option.
It looks like any config option starting with HAVE_ is not selectable.
On Tuesday, 10 October 2023 12:10:07 CEST Emanuele Rocca wrote:
> SUSE and Fedora both seem to have CONFIG_HAVE_PREEMPT_DYNAMIC=y on
> arm64, see:
> https://github.com/SUSE/kernel-source/blob/SLE15-SP6/config/arm64/default#L1
> 23 https://src.fedoraproject.org/rpms/kernel/blob/f34/f/kernel.spec#_4458
>
> Setting CONFIG_HAVE_PREEMPT_DYNAMIC=y on arm64 is likely safe for us
> too, but we may want to run some benchmark first to see if there are any
> noticeable slowdowns.
Similarly, you *can't* explicitly/directly enable HAVE_PREEMPT_DYNAMIC.
> > I think it should be explicitly enabled (or disabled) and not be it
> > dependent on some other, possibly unrelated, Kconfig option being enabled
It seems an important difference between your view and mine is that you look at
the end result, while I look at what's configured in the Debian kernel repo.
While some options are enabled in the end result, NONE is configured in the
Debian kernel repo. And that could have major, unwanted, consequences.
I don't know if it's the right call to do so, but PREEMPT_DYNAMIC *is*
directly/explicitly selectable and if that's what we want, then we should make
that setting in the Debian kernel repo.
> From the PREEMPT_DYNAMIC Kconfig help:
>
> The runtime overhead is negligible with HAVE_STATIC_CALL_INLINE enabled
> but if runtime patching is not available for the specific architecture
> then the potential overhead should be considered.
>
> > ad 1) I _think_ running benchmarks is not that useful as its result
> > will/should vary based on the default preemption model and whether that
> > is overridden on the kernel command line
>
> Sorry, I wasn't clear in my previous message about what we should be
> benchmarking. The current Debian kernel on arm64 has PREEMPT_VOLUNTARY=y
> and PREEMPT_DYNAMIC not set. We want to run benchmarks to see if a
> kernel with PREEMPT_DYNAMIC=y booted with preempt=voluntary has any
> significant slowdowns compared to the current kernels. We don't want to
> benchmark the various preemption models.
Ok, thanks for the clarification.
signature.asc
Description: This is a digitally signed message part.
