From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7401D30EF91 for ; Fri, 7 Aug 2026 01:54:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786067663; cv=none; b=Jaj4AAP6MsO+mPyKwaBZIlp/c3KTl5XuhMV862dMp0MiC5WDYMEqJ+96TkHL6J7BRui81QA5JWbAgSbR6eDwhy0C8KNpjWVsB5Ua5M7rhIpUUUz7beIIl1etvQQamg6p5+LGQtg3Oi23aMBZhxgHNbrpY9swzxpw9GQNejdK/wQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786067663; c=relaxed/simple; bh=s1IzfdmRmJMObN7yTkGcXuRq2vZxwWopyHKZBue/bMc=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=XcgiqJVzdswBhJjnq4apoIIxupLtdX+fXHOAj6caBKpaZhO1li9ek6P/ZQCRYkwGP950lEr0ISCJb2OqlND/EnndmOQ8pGOZXMPffKSxxMFPeb7lpyWGGL4zAa8cEP7RiBJO3qd8q2KO1vqGh28nMIOnzg98Ir5gaciNnC+s3xg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=BcBxPSRo; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="BcBxPSRo" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=6g5cG1PW6gZEy/0Z/MYol8Vmzv43cdvmBOvs4QxMtWQ=; b=BcBxPSRopzJHegDaGns65YY5UGYKgEGHx8UuspMr5sqcp9e7gIOsXuRzCFMBBTXzOyoKWDgmY GwWWvFWihghLpNmEYO8Mja/r8l/l61lXC7oXg056znfdM6EbPmVyjIu5RhEX1gZ1dCmSzkV0fXr WMFxOaSkb7oPUUOB7+itP6M= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4hGRlQ1wKTzcb0T; Fri, 7 Aug 2026 09:44:18 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id B9F354057F; Fri, 7 Aug 2026 09:54:15 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 7 Aug 2026 09:54:14 +0800 Message-ID: <65b9ac80-1503-41ad-adee-59f9260fe4e0@huawei.com> Date: Fri, 7 Aug 2026 09:54:13 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/6] sched: dynamic: Remove HAVE_PREEMPT_DYNAMIC_{CALL,KEY} To: Mark Rutland , CC: , , , , , , , , , References: <20260803191731.3244294-1-mark.rutland@arm.com> <20260803191731.3244294-6-mark.rutland@arm.com> From: Jinjie Ruan In-Reply-To: <20260803191731.3244294-6-mark.rutland@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To dggpemf500011.china.huawei.com (7.185.36.131) 在 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 > Cc: Frederic Weisbecker > Cc: Ingo Molnar > Cc: John Stultz > Cc: Juri Lelli > Cc: Peter Zijlstra > Cc: Shrikanth Hegde > Cc: Thomas Gleixner > Cc: Valentin Schneider > Cc: Vincent Guittot > --- > 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 > 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)