Lazy preemption on arm64

Lazy preemption on arm64

[Petr Tesarik]

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?

Cheers
Petr T

Re: Lazy preemption on arm64

[Mark Rutland]

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

Re: Lazy preemption on arm64

[gene heskett]

On 12/16/24 14:05, Mark Rutland wrote:
> 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?
For running machine tools with LinuxCNC, very.  I have an rpi4b running 
a medium sized Sheldon lathe thats all of 80 yo  and its still using a 
4.19-rt kernel with quite low for a pi, latency.  But its 10x slower 
than wintel stuff.
>
> 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)

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

Re: Lazy preemption on arm64

[Petr Tesarik]

On Mon, 16 Dec 2024 19:04:43 +0000
Mark Rutland <mark.rutland@arm.com> wrote:

> 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.

Thanks for confirmation. Being a newcomer to RT, I wasn't sure.

> Jinjie Ruan has been looking to move arm64 over to GENERIC_ENTRY:
> 
>   https://lore.kernel.org/all/20241206101744.4161990-1-ruanjinjie@huawei.com/

Thank you for the link.

> 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.

Yes, that's also my understanding.

> ... so how important is this?

For whom? For my work, this is very important. ;-)

We have decided to upgrade RT to v6.12 for the next SUSE product (so we
can finally get rid of many out-of-tree patches), but we are now facing
a regression on arm64. Since we generally follow an upstream-first
policy, adding an out-of-tree patch like below is undesirable (but not
impossible if there is no better alternative).

It seems to me that the conversion to generic entry is going to happen,
but the current patch series (v5) may still have issues (many changes
from v4 and no review yet), so we'll have to accept some divergence
from mainline...

Thank you for sharing your insight!

Petr T

> 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)

Re: Lazy preemption on arm64

[Petr Tesarik]

V Mon, 16 Dec 2024 19:04:43 +0000
Mark Rutland <mark.rutland@arm.com> napsáno:

> 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.

@bigeasy: Would it be OK for you to add the below patch to the next
6.13 RT patches?

Mark tagged it with "HACK", but to me it actually looks just as good as
the good old (pre-PREEMPT_AUTO) arm64 patch. ;-)

Petr T

> ---->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)

Re: Lazy preemption on arm64

[Sebastian Andrzej Siewior]

On 2024-12-17 07:31:51 [+0100], Petr Tesarik wrote:
> V Mon, 16 Dec 2024 19:04:43 +0000
> Mark Rutland <mark.rutland@arm.com> napsáno:
> 
> > 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.
> 
> @bigeasy: Would it be OK for you to add the below patch to the next
> 6.13 RT patches?

This bits below are actually the same ones I made last week. I stopped
there because it was late and I didn't find GENERIC_ENTRY nor a
TIF_NEED_RESCHED check in arm64 so I paused. Where is this?

Other than that I would be happy to take it then hoping arm64 does the
same.

> Mark tagged it with "HACK", but to me it actually looks just as good as
> the good old (pre-PREEMPT_AUTO) arm64 patch. ;-)

The old lazy-preempt had also tweaks in should_resched() and
__preempt_count_dec_and_test(). So it is slightly different.

> Petr T

Sebastian

Re: Lazy preemption on arm64

[Mark Rutland]

On Tue, Dec 17, 2024 at 09:50:31AM +0100, Sebastian Andrzej Siewior wrote:
> On 2024-12-17 07:31:51 [+0100], Petr Tesarik wrote:
> > V Mon, 16 Dec 2024 19:04:43 +0000
> > Mark Rutland <mark.rutland@arm.com> napsáno:
> > 
> > > 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.
> > 
> > @bigeasy: Would it be OK for you to add the below patch to the next
> > 6.13 RT patches?
> 
> This bits below are actually the same ones I made last week. I stopped
> there because it was late and I didn't find GENERIC_ENTRY nor a
> TIF_NEED_RESCHED check in arm64 so I paused. Where is this?

Currently arm64 doesn't use GENERIC_ENTRY; people are working on that
(see the link above), but it's likely to take a short while. IIUC
there's no strict dependency on GENERIC_ENTRY here, unless I'm missing
something?

For TIF_NEED_RESCHED, arm64 relies upon the core code to call
set_preempt_need_resched() (e.g. via preempt_fold_need_resched()) to
fold that into thread_info::preempt::need_resched. That's checked by
arm64_preempt_schedule_irq(), which reads thread_info::preempt_count,
which is unioned with thread_info::preempt::{count,need_resched} such
that the two fields can be checked together.

> Other than that I would be happy to take it then hoping arm64 does the
> same.

If PREEMPT_LAZY is something that people need urgently then I can go
turn the hack into a proepr patch and see if we can queue that ahead of
the larger rework for GENERIC_ENTRY.

> > Mark tagged it with "HACK", but to me it actually looks just as good as
> > the good old (pre-PREEMPT_AUTO) arm64 patch. ;-)
> 
> The old lazy-preempt had also tweaks in should_resched() and
> __preempt_count_dec_and_test(). So it is slightly different.

Hmm... what needed to change there?

Currently we're relying on the union trick to check both
thread_info::preempt::{count,need_resched}, where the latter should have
TIF_NEED_RESCHED folded in (but not TIF_NEED_RESCHED_LAZY), which IIUC
is sufficient?

Mark.

Re: Lazy preemption on arm64

[Sebastian Andrzej Siewior]

On 2024-12-17 11:34:43 [+0000], Mark Rutland wrote:
> On Tue, Dec 17, 2024 at 09:50:31AM +0100, Sebastian Andrzej Siewior wrote:
> > On 2024-12-17 07:31:51 [+0100], Petr Tesarik wrote:
> > > V Mon, 16 Dec 2024 19:04:43 +0000
> > > Mark Rutland <mark.rutland@arm.com> napsáno:
> > > 
> > > > 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.
> > > 
> > > @bigeasy: Would it be OK for you to add the below patch to the next
> > > 6.13 RT patches?
> > 
> > This bits below are actually the same ones I made last week. I stopped
> > there because it was late and I didn't find GENERIC_ENTRY nor a
> > TIF_NEED_RESCHED check in arm64 so I paused. Where is this?
> 
> Currently arm64 doesn't use GENERIC_ENTRY; people are working on that
> (see the link above), but it's likely to take a short while. IIUC
> there's no strict dependency on GENERIC_ENTRY here, unless I'm missing
> something?

No, not really, that is perfect.

> For TIF_NEED_RESCHED, arm64 relies upon the core code to call
> set_preempt_need_resched() (e.g. via preempt_fold_need_resched()) to
> fold that into thread_info::preempt::need_resched. That's checked by
> arm64_preempt_schedule_irq(), which reads thread_info::preempt_count,
> which is unioned with thread_info::preempt::{count,need_resched} such
> that the two fields can be checked together.

All sounds fine. Now, if that bit is set, we need schedule() before
returning to userland. I didn't it initially but now I did:

diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index b260ddc4d3e9a..2e2f13ce076da 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)

With that piece we should be fine.

> > Other than that I would be happy to take it then hoping arm64 does the
> > same.
> 
> If PREEMPT_LAZY is something that people need urgently then I can go
> turn the hack into a proepr patch and see if we can queue that ahead of
> the larger rework for GENERIC_ENTRY.

I would appreciate it. However if there is reason to delay it I could
hold to it for some time…

> > > Mark tagged it with "HACK", but to me it actually looks just as good as
> > > the good old (pre-PREEMPT_AUTO) arm64 patch. ;-)
> > 
> > The old lazy-preempt had also tweaks in should_resched() and
> > __preempt_count_dec_and_test(). So it is slightly different.
> 
> Hmm... what needed to change there?
> 
> Currently we're relying on the union trick to check both
> thread_info::preempt::{count,need_resched}, where the latter should have
> TIF_NEED_RESCHED folded in (but not TIF_NEED_RESCHED_LAZY), which IIUC
> is sufficient?

The old lazy-preempt dates back to around v3.0-RT+. The logic back then
was slightly different and had also a counter (similar to the counter
used by preempt_disable()) so we had to ensure preempt_enable() does not
schedule if the lazy-counter > 0 and the caller was not a RT task.
With the improvements over time and the current design a lot of the old
cruft simply removed. So nothing to worry :)

> Mark.

Sebastian

Re: Lazy preemption on arm64

[Mark Rutland]

On Tue, Dec 17, 2024 at 12:59:31PM +0100, Sebastian Andrzej Siewior wrote:
> On 2024-12-17 11:34:43 [+0000], Mark Rutland wrote:
> > On Tue, Dec 17, 2024 at 09:50:31AM +0100, Sebastian Andrzej Siewior wrote:
> > > This bits below are actually the same ones I made last week. I stopped
> > > there because it was late and I didn't find GENERIC_ENTRY nor a
> > > TIF_NEED_RESCHED check in arm64 so I paused. Where is this?
> > 
> > Currently arm64 doesn't use GENERIC_ENTRY; people are working on that
> > (see the link above), but it's likely to take a short while. IIUC
> > there's no strict dependency on GENERIC_ENTRY here, unless I'm missing
> > something?
> 
> No, not really, that is perfect.
> 
> > For TIF_NEED_RESCHED, arm64 relies upon the core code to call
> > set_preempt_need_resched() (e.g. via preempt_fold_need_resched()) to
> > fold that into thread_info::preempt::need_resched. That's checked by
> > arm64_preempt_schedule_irq(), which reads thread_info::preempt_count,
> > which is unioned with thread_info::preempt::{count,need_resched} such
> > that the two fields can be checked together.
> 
> All sounds fine. Now, if that bit is set, we need schedule() before
> returning to userland. I didn't it initially but now I did:
> 
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index b260ddc4d3e9a..2e2f13ce076da 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)
> 
> With that piece we should be fine.

Yep, I had that in my HACK patch:

  https://lore.kernel.org/linux-rt-users/20241217115931.wjw_HO2V@linutronix.de/T/#m12eece66786a3a207e4e952bdf58570ab75c6a89

... so it sounds like we're on the same page. :)

> > > Other than that I would be happy to take it then hoping arm64 does the
> > > same.
> > 
> > If PREEMPT_LAZY is something that people need urgently then I can go
> > turn the hack into a proepr patch and see if we can queue that ahead of
> > the larger rework for GENERIC_ENTRY.
> 
> I would appreciate it. However if there is reason to delay it I could
> hold to it for some time…

I'll try to spin it as a proper patch later this week (and will Cc the
folk here, along with Jinjie, etc); it'll be up to Will and Catalin as
to whether they're happy to pick it up, but given it's small I suspect
that'll be fine.

> > > > Mark tagged it with "HACK", but to me it actually looks just as good as
> > > > the good old (pre-PREEMPT_AUTO) arm64 patch. ;-)
> > > 
> > > The old lazy-preempt had also tweaks in should_resched() and
> > > __preempt_count_dec_and_test(). So it is slightly different.
> > 
> > Hmm... what needed to change there?
> > 
> > Currently we're relying on the union trick to check both
> > thread_info::preempt::{count,need_resched}, where the latter should have
> > TIF_NEED_RESCHED folded in (but not TIF_NEED_RESCHED_LAZY), which IIUC
> > is sufficient?
> 
> The old lazy-preempt dates back to around v3.0-RT+. The logic back then
> was slightly different and had also a counter (similar to the counter
> used by preempt_disable()) so we had to ensure preempt_enable() does not
> schedule if the lazy-counter > 0 and the caller was not a RT task.
> With the improvements over time and the current design a lot of the old
> cruft simply removed. So nothing to worry :)

Phew, thanks for confirming!

Mark.

Re: Lazy preemption on arm64

[Sebastian Andrzej Siewior]

On 2024-12-17 12:23:18 [+0000], Mark Rutland wrote:
> Yep, I had that in my HACK patch:
> 
>   https://lore.kernel.org/linux-rt-users/20241217115931.wjw_HO2V@linutronix.de/T/#m12eece66786a3a207e4e952bdf58570ab75c6a89
> 
> ... so it sounds like we're on the same page. :)

That is great then. I somehow accounted this for the KVM bits but you
have KVM_XFER_TO_GUEST_WORK so it is all good.

> > I would appreciate it. However if there is reason to delay it I could
> > hold to it for some time…
> 
> I'll try to spin it as a proper patch later this week (and will Cc the
> folk here, along with Jinjie, etc); it'll be up to Will and Catalin as
> to whether they're happy to pick it up, but given it's small I suspect
> that'll be fine.
Okay.

> Mark.

Sebastian

Re: Lazy preemption on arm64

[Mike Galbraith]

Greetings,

On Tue, 2024-12-17 at 12:23 +0000, Mark Rutland wrote:
> On Tue, Dec 17, 2024 at 12:59:31PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2024-12-17 11:34:43 [+0000], Mark Rutland wrote:
> > > On Tue, Dec 17, 2024 at 09:50:31AM +0100, Sebastian Andrzej Siewior wrote:
> > > > This bits below are actually the same ones I made last week. I stopped
> > > > there because it was late and I didn't find GENERIC_ENTRY nor a
> > > > TIF_NEED_RESCHED check in arm64 so I paused. Where is this?
> > >
> > > Currently arm64 doesn't use GENERIC_ENTRY; people are working on that
> > > (see the link above), but it's likely to take a short while. IIUC
> > > there's no strict dependency on GENERIC_ENTRY here, unless I'm missing
> > > something?
> >
> > No, not really, that is perfect.
> >
> > > For TIF_NEED_RESCHED, arm64 relies upon the core code to call
> > > set_preempt_need_resched() (e.g. via preempt_fold_need_resched()) to
> > > fold that into thread_info::preempt::need_resched. That's checked by
> > > arm64_preempt_schedule_irq(), which reads thread_info::preempt_count,
> > > which is unioned with thread_info::preempt::{count,need_resched} such
> > > that the two fields can be checked together.
> >
> > All sounds fine. Now, if that bit is set, we need schedule() before
> > returning to userland. I didn't it initially but now I did:
> >
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index b260ddc4d3e9a..2e2f13ce076da 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)
> >
> > With that piece we should be fine.
>
> Yep, I had that in my HACK patch:
>
>   https://lore.kernel.org/linux-rt-users/20241217115931.wjw_HO2V@linutronix.de/T/#m12eece66786a3a207e4e952bdf58570ab75c6a89

Posting this for mainline inclusion was suggested, but I don't see
waiting for GENERIC_ENTRY as having any meaningful impact for the
general case, everyone's used to whatever preemption model they've been
using.  OTOH, not having PREEMPT_LAZY for RT users has been having at
least some impact, which your patch can alleviate, so I'll post the
fixed up and lightly tested version here... including something
resembling a changelog in case anyone disagrees about submission, but
is too lazy to write the way better one they most definitely should :)

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

GENERIC_ENTRY is not yet implemented for arm64, but is in the pipe.
Meanwhile, the below can serve to bridge the gap, particularly for
those building/running PREEMPT_RT kernels, where lazy preemption
markedly improves SCHED_OTHER load component throughput.

Mike: testdrive, _TIF_WORK_MASK fixlet and changelog.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
---
 arch/arm64/Kconfig                   |    1 +
 arch/arm64/include/asm/thread_info.h |   16 +++++++++-------
 arch/arm64/kernel/entry-common.c     |    2 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

--- 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
--- 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)
@@ -100,10 +102,10 @@ void arch_setup_new_exec(void);
 #define _TIF_NOTIFY_SIGNAL	(1 << TIF_NOTIFY_SIGNAL)
 #define _TIF_TSC_SIGSEGV	(1 << TIF_TSC_SIGSEGV)

-#define _TIF_WORK_MASK		(_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
+#define _TIF_WORK_MASK		(_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY | \
 				 _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
 				 _TIF_UPROBE | _TIF_MTE_ASYNC_FAULT | \
-				 _TIF_NOTIFY_SIGNAL)
+				 _TIF_NOTIFY_SIGNAL | _TIF_SIGPENDING)

 #define _TIF_SYSCALL_WORK	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
 				 _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
--- 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_r
 	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)