Re: [PATCH v2 5/6] sched: dynamic: Remove HAVE_PREEMPT_DYNAMIC_{CALL,KEY}

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/8/4 3:17, Mark Rutland 写道:
> PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models.
> Switching model only changes the behaviour of dynamic_preempt_lazy(),
> which uses a static key. There are no other static calls or static keys,
> and so there's no need for HAVE_PREEMPT_DYNAMIC_CALL or
> HAVE_PREEMPT_DYNAMIC_KEY.
> 
> The static key used by dynamic_preempt_lazy() is entirely local to
> kernel/sched/core.c, and any architecture which selects
> ARCH_HAS_PREEMPT_LAZY implements the necessary support. Remove
> PREEMPT_DYNAMIC's dependencies on HAVE_PREEMPT_DYNAMIC_CALL and
> HAVE_PREEMPT_DYNAMIC_KEY entirely, leaving the dependency on
> ARCH_HAS_PREEMPT_LAZY.
> 
> For architectures which previously selected HAVE_PREEMPT_DYNAMIC_KEY,
> PREEMPT_DYNAMIC will now be selected by default, matching x86. As the
> runtime impact is limited to dynamic_preempt_lazy(), this shouldn't be
> as concerning as previously (e.g. where calls to {cond,might}_resched()
> stubs could introduce a measurable penalty).
> 
> As all of this can work without jump labels, JUMP_LABEL is not selected
> explicitly. It is obviously preferable to have JUMP_LABEL enabled, but
> this is not functionally necessary.
> 
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: John Stultz <jstultz@google.com>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Valentin Schneider <vschneid@redhat.com>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  arch/Kconfig           | 38 --------------------------------------
>  arch/arm64/Kconfig     |  1 -
>  arch/loongarch/Kconfig |  1 -
>  arch/powerpc/Kconfig   |  1 -
>  arch/riscv/Kconfig     |  1 -
>  arch/s390/Kconfig      |  1 -
>  arch/x86/Kconfig       |  1 -
>  kernel/Kconfig.preempt |  8 ++------
>  kernel/sched/core.c    | 10 ----------
>  9 files changed, 2 insertions(+), 60 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index fa7507ac8e13e..16e46010922a5 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1696,44 +1696,6 @@ config HAVE_STATIC_CALL_INLINE
>  	depends on HAVE_STATIC_CALL
>  	select OBJTOOL
>  
> -config HAVE_PREEMPT_DYNAMIC
> -	bool
> -
> -config HAVE_PREEMPT_DYNAMIC_CALL
> -	bool
> -	depends on HAVE_STATIC_CALL
> -	select HAVE_PREEMPT_DYNAMIC
> -	help
> -	  An architecture should select this if it can handle the preemption
> -	  model being selected at boot time using static calls.
> -
> -	  Where an architecture selects HAVE_STATIC_CALL_INLINE, any call to a
> -	  preemption function will be patched directly.
> -
> -	  Where an architecture does not select HAVE_STATIC_CALL_INLINE, any
> -	  call to a preemption function will go through a trampoline, and the
> -	  trampoline will be patched.
> -
> -	  It is strongly advised to support inline static call to avoid any
> -	  overhead.
> -
> -config HAVE_PREEMPT_DYNAMIC_KEY
> -	bool
> -	depends on HAVE_ARCH_JUMP_LABEL
> -	select HAVE_PREEMPT_DYNAMIC
> -	help
> -	  An architecture should select this if it can handle the preemption
> -	  model being selected at boot time using static keys.
> -
> -	  Each preemption function will be given an early return based on a
> -	  static key. This should have slightly lower overhead than non-inline
> -	  static calls, as this effectively inlines each trampoline into the
> -	  start of its callee. This may avoid redundant work, and may
> -	  integrate better with CFI schemes.
> -
> -	  This will have greater overhead than using inline static calls as
> -	  the call to the preemption function cannot be entirely elided.
> -

That's in line with my expectations.

>  config ARCH_WANT_LD_ORPHAN_WARN
>  	bool
>  	help
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b3afe0688919b..1504bc354b9e5 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -216,7 +216,6 @@ config ARM64
>  	select HAVE_PERF_EVENTS_NMI if ARM64_PSEUDO_NMI
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
> -	select HAVE_PREEMPT_DYNAMIC_KEY
>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RELIABLE_STACKTRACE
>  	select HAVE_POSIX_CPU_TIMERS_TASK_WORK
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index d8d2523250179..1889d808597da 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -170,7 +170,6 @@ config LOONGARCH
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
>  	select HAVE_POSIX_CPU_TIMERS_TASK_WORK
> -	select HAVE_PREEMPT_DYNAMIC_KEY

select JUMP_LABEL?

>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RELIABLE_STACKTRACE if UNWINDER_ORC
>  	select HAVE_RETHOOK
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index f7ce5fff81f03..940f8fbea55c5 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -280,7 +280,6 @@ config PPC
>  	select HAVE_PERF_EVENTS_NMI		if PPC64
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
> -	select HAVE_PREEMPT_DYNAMIC_KEY

select JUMP_LABEL?

>  	select HAVE_RETHOOK			if KPROBES
>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RELIABLE_STACKTRACE
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index f7028caaeae06..9c1207a0cbcb9 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -193,7 +193,6 @@ config RISCV
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
>  	select HAVE_POSIX_CPU_TIMERS_TASK_WORK
> -	select HAVE_PREEMPT_DYNAMIC_KEY

select JUMP_LABEL?

>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RETHOOK
>  	select HAVE_RSEQ
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 84404e6778d50..ad527859694ab 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -239,7 +239,6 @@ config S390
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
>  	select HAVE_POSIX_CPU_TIMERS_TASK_WORK
> -	select HAVE_PREEMPT_DYNAMIC_KEY

select JUMP_LABEL?

>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RELIABLE_STACKTRACE
>  	select HAVE_RETHOOK
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index bdad90f210e4b..b05ffa8f661b4 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -294,7 +294,6 @@ config X86
>  	select HAVE_STACK_VALIDATION		if HAVE_OBJTOOL
>  	select HAVE_STATIC_CALL
>  	select HAVE_STATIC_CALL_INLINE		if HAVE_OBJTOOL
> -	select HAVE_PREEMPT_DYNAMIC_CALL
>  	select HAVE_RSEQ
>  	select HAVE_RUST			if X86_64
>  	select HAVE_SYSCALL_TRACEPOINTS
> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> index fb49424003b2b..87d567680bc74 100644
> --- a/kernel/Kconfig.preempt
> +++ b/kernel/Kconfig.preempt
> @@ -128,11 +128,9 @@ config PREEMPTION
>  
>  config PREEMPT_DYNAMIC
>  	bool "Preemption behaviour defined on boot"
> -	depends on HAVE_PREEMPT_DYNAMIC
>  	depends on ARCH_HAS_PREEMPT_LAZY
> -	select JUMP_LABEL if HAVE_PREEMPT_DYNAMIC_KEY

After this, only the arm64 architecture explicitly selects JUMP_LABEL.
When we remove the dependency on HAVE_PREEMPT_DYNAMIC_KEY, should we
also select JUMP_LABEL for those architectures.

git grep "select JUMP_LABEL"
arch/arm64/Kconfig:     select JUMP_LABEL
block/Kconfig:  select JUMP_LABEL if HAVE_ARCH_JUMP_LABEL
fs/xfs/Kconfig: select JUMP_LABEL if HAVE_ARCH_JUMP_LABEL
fs/xfs/Kconfig: select JUMP_LABEL if HAVE_ARCH_JUMP_LABEL

otherwise
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>

>  	select PREEMPT_BUILD
> -	default y if HAVE_PREEMPT_DYNAMIC_CALL
> +	default y
>  	help
>  	  This option allows to define the preemption model on the kernel
>  	  command line parameter and thus override the default preemption
> @@ -142,9 +140,7 @@ config PREEMPT_DYNAMIC
>  	  provide a pre-built kernel binary to reduce the number of kernel
>  	  flavors they offer while still offering different usecases.
>  
> -	  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.
> +	  The runtime overhead is negligible.
>  
>  	  Interesting if you want the same pre-built kernel should be used for
>  	  both Server and Desktop workloads.
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 4f754f4a472f8..7b815d8ce67d3 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7825,16 +7825,6 @@ int sched_dynamic_mode(const char *str)
>  # define preempt_dynamic_key_enable(f)	static_key_enable(&sk_dynamic_##f.key)
>  # define preempt_dynamic_key_disable(f)	static_key_disable(&sk_dynamic_##f.key)
>  
> -# if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL)
> -#  define preempt_dynamic_enable(f)	static_call_update(f, f##_dynamic_enabled)
> -#  define preempt_dynamic_disable(f)	static_call_update(f, f##_dynamic_disabled)
> -# elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY)
> -#  define preempt_dynamic_enable(f)	preempt_dynamic_key_enable(f)
> -#  define preempt_dynamic_disable(f)	preempt_dynamic_key_disable(f)
> -# else
> -#  error "Unsupported PREEMPT_DYNAMIC mechanism"
> -# endif
> -
>  static DEFINE_MUTEX(sched_dynamic_mutex);
>  
>  static void __sched_dynamic_update(int mode)