From: Mark Rutland <mark.rutland@arm.com>
To: Petr Tesarik <ptesarik@suse.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Lazy preemption on arm64
Date: Mon, 16 Dec 2024 19:04:43 +0000 [thread overview]
Message-ID: <Z2B5y3HiLuRHPfdv@J2N7QTR9R3.cambridge.arm.com> (raw)
In-Reply-To: <20241216190451.1c61977c@mordecai.tesarici.cz>
On Mon, Dec 16, 2024 at 07:04:51PM +0100, Petr Tesarik wrote:
> Hi all,
>
> what is the plan for implementing PREEMPT_LAZY on arm64?
>
> There used to be RT patch series which enabled lazy preemption on
> arm64, but this architecture was "sacrificed" in v6.6-rc6-rt10, as
> collateral damage of switching to PREEMPT_AUTO.
>
> IIUC lazy preemption is currently implemented only for architectures
> with CONFIG_GENERIC_ENTRY, but there is no inherent dependency on it.
> So, is the plan to convert arm64 to GENERIC_ENTRY (and then get
> PREEMPT_LAZY for free), or is somebody working on CONFIG_PREEMPT_LAZY
> for arm64 without that conversion?
I don't think there's an agreed upon plan either way.
Jinjie Ruan has been looking to move arm64 over to GENERIC_ENTRY:
https://lore.kernel.org/all/20241206101744.4161990-1-ruanjinjie@huawei.com/
AFAICT, the only bits that we get "for free" from GENERIC_ENTRY would be
the logic in raw_irqentry_exit_cond_resched() and
exit_to_user_mode_loop(), and all we'd need to enable this on arm64
as-is would be as below.
... so how important is this?
Mark.
---->8----
From 16ae3c84d8e1691fe670dbfb4c643cab4fa2065f Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 16 Dec 2024 18:32:44 +0000
Subject: [PATCH] HACK: arm64: enable PREEMPT_LAZY
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/thread_info.h | 12 +++++++-----
arch/arm64/kernel/entry-common.c | 2 +-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 100570a048c5e..7926bc78a1c46 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -39,6 +39,7 @@ config ARM64
select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_NONLEAF_PMD_YOUNG if ARM64_HAFT
+ select ARCH_HAS_PREEMPT_LAZY
select ARCH_HAS_PTE_DEVMAP
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_HW_PTE_YOUNG
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 1114c1c3300a1..a2125407901ed 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -59,11 +59,12 @@ void arch_setup_new_exec(void);
#define TIF_SIGPENDING 0 /* signal pending */
#define TIF_NEED_RESCHED 1 /* rescheduling necessary */
-#define TIF_NOTIFY_RESUME 2 /* callback before returning to user */
-#define TIF_FOREIGN_FPSTATE 3 /* CPU's FP state is not current's */
-#define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */
-#define TIF_MTE_ASYNC_FAULT 5 /* MTE Asynchronous Tag Check Fault */
-#define TIF_NOTIFY_SIGNAL 6 /* signal notifications exist */
+#define TIF_NEED_RESCHED_LAZY 2 /* Lazy rescheduling needed */
+#define TIF_NOTIFY_RESUME 3 /* callback before returning to user */
+#define TIF_FOREIGN_FPSTATE 4 /* CPU's FP state is not current's */
+#define TIF_UPROBE 5 /* uprobe breakpoint or singlestep */
+#define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */
+#define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */
#define TIF_SYSCALL_TRACE 8 /* syscall trace active */
#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */
#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */
@@ -85,6 +86,7 @@ void arch_setup_new_exec(void);
#define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
+#define _TIF_NEED_RESCHED_LAZY (1 << TIF_NEED_RESCHED_LAZY)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
#define _TIF_FOREIGN_FPSTATE (1 << TIF_FOREIGN_FPSTATE)
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index b260ddc4d3e9a..7993fab0cab4c 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -132,7 +132,7 @@ static void do_notify_resume(struct pt_regs *regs, unsigned long thread_flags)
do {
local_irq_enable();
- if (thread_flags & _TIF_NEED_RESCHED)
+ if (thread_flags & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY))
schedule();
if (thread_flags & _TIF_UPROBE)
--
2.30.2
next prev parent reply other threads:[~2024-12-16 19:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 18:04 Lazy preemption on arm64 Petr Tesarik
2024-12-16 19:04 ` Mark Rutland [this message]
2024-12-17 0:40 ` gene heskett
2024-12-17 6:03 ` Petr Tesarik
2024-12-17 6:31 ` Petr Tesarik
2024-12-17 8:50 ` Sebastian Andrzej Siewior
2024-12-17 11:34 ` Mark Rutland
2024-12-17 11:59 ` Sebastian Andrzej Siewior
2024-12-17 12:23 ` Mark Rutland
2024-12-17 12:56 ` Sebastian Andrzej Siewior
2025-02-14 7:34 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z2B5y3HiLuRHPfdv@J2N7QTR9R3.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=ptesarik@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox