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

Jinjie Ruan <[email protected]>
Newsgroups org.kernel.vger.linux-kernel
Message-ID <[email protected]>

在 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 <[email protected]>
> Cc: Frederic Weisbecker <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: John Stultz <[email protected]>
> Cc: Juri Lelli <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Shrikanth Hegde <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Valentin Schneider <[email protected]>
> Cc: Vincent Guittot <[email protected]>
> ---
>  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 <[email protected]>

>  	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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.