[PATCH] x86/fpu: don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[PATCH] x86/fpu: don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[Jens Axboe]

We don't set it on PF_KTHREAD threads as they never return to userspace,
and PF_IO_WORKER threads are identical in that regard. As they keep
running in the kernel until they die, skip setting the FPU flag on them.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

---

Not urgent, more of a cosmetic thing that was found while debugging and
issue and pondering why the FPU flag is set on these threads.

diff --git a/arch/x86/include/asm/fpu/sched.h b/arch/x86/include/asm/fpu/sched.h
index b2486b2cbc6e..c2d6cd78ed0c 100644
--- a/arch/x86/include/asm/fpu/sched.h
+++ b/arch/x86/include/asm/fpu/sched.h
@@ -39,7 +39,7 @@ extern void fpu_flush_thread(void);
 static inline void switch_fpu_prepare(struct fpu *old_fpu, int cpu)
 {
 	if (cpu_feature_enabled(X86_FEATURE_FPU) &&
-	    !(current->flags & PF_KTHREAD)) {
+	    !(current->flags & (PF_KTHREAD | PF_IO_WORKER))) {
 		save_fpregs_to_fpstate(old_fpu);
 		/*
 		 * The save operation preserved register state, so the
diff --git a/arch/x86/kernel/fpu/context.h b/arch/x86/kernel/fpu/context.h
index 958accf2ccf0..9fcfa5c4dad7 100644
--- a/arch/x86/kernel/fpu/context.h
+++ b/arch/x86/kernel/fpu/context.h
@@ -57,7 +57,7 @@ static inline void fpregs_restore_userregs(void)
 	struct fpu *fpu = &current->thread.fpu;
 	int cpu = smp_processor_id();
 
-	if (WARN_ON_ONCE(current->flags & PF_KTHREAD))
+	if (WARN_ON_ONCE(current->flags & (PF_KTHREAD | PF_IO_WORKER)))
 		return;
 
 	if (!fpregs_state_valid(fpu, cpu)) {
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 9baa89a8877d..2babc537ff36 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -426,7 +426,7 @@ void kernel_fpu_begin_mask(unsigned int kfpu_mask)
 
 	this_cpu_write(in_kernel_fpu, true);
 
-	if (!(current->flags & PF_KTHREAD) &&
+	if (!(current->flags & (PF_KTHREAD | PF_IO_WORKER)) &&
 	    !test_thread_flag(TIF_NEED_FPU_LOAD)) {
 		set_thread_flag(TIF_NEED_FPU_LOAD);
 		save_fpregs_to_fpstate(&current->thread.fpu);

-- 
Jens Axboe

Re: [PATCH] x86/fpu: don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[Peter Zijlstra]

On Tue, Jan 24, 2023 at 08:23:20AM -0700, Jens Axboe wrote:
> We don't set it on PF_KTHREAD threads as they never return to userspace,
> and PF_IO_WORKER threads are identical in that regard. As they keep
> running in the kernel until they die, skip setting the FPU flag on them.

No objection to the actual patch; but this changelog fails to tell us
why this is important.

What made you get up and write this patch :-) Presumably this is a
performance issue? If so, can you quantify how much?

Re: [PATCH] x86/fpu: don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[Jens Axboe]

On 1/24/23 8:40 AM, Peter Zijlstra wrote:
> On Tue, Jan 24, 2023 at 08:23:20AM -0700, Jens Axboe wrote:
>> We don't set it on PF_KTHREAD threads as they never return to userspace,
>> and PF_IO_WORKER threads are identical in that regard. As they keep
>> running in the kernel until they die, skip setting the FPU flag on them.
> 
> No objection to the actual patch; but this changelog fails to tell us
> why this is important.
> 
> What made you get up and write this patch :-) Presumably this is a
> performance issue? If so, can you quantify how much?

You snipped the part where that was explained, but arguably that should
probably go into the commit message itself:

"Not urgent, more of a cosmetic thing that was found while debugging and
issue and pondering why the FPU flag is set on these threads."

So it's not really a performance issue, it was just something odd that
got me scratching my head when debugging another issue and poking at
the flags.

Want a resend of it, or will you just augment the commit message?

-- 
Jens Axboe

Re: [PATCH] x86/fpu: don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[Peter Zijlstra]

On Tue, Jan 24, 2023 at 09:06:08AM -0700, Jens Axboe wrote:
> On 1/24/23 8:40 AM, Peter Zijlstra wrote:
> > On Tue, Jan 24, 2023 at 08:23:20AM -0700, Jens Axboe wrote:
> >> We don't set it on PF_KTHREAD threads as they never return to userspace,
> >> and PF_IO_WORKER threads are identical in that regard. As they keep
> >> running in the kernel until they die, skip setting the FPU flag on them.
> > 
> > No objection to the actual patch; but this changelog fails to tell us
> > why this is important.
> > 
> > What made you get up and write this patch :-) Presumably this is a
> > performance issue? If so, can you quantify how much?
> 
> You snipped the part where that was explained, but arguably that should
> probably go into the commit message itself:
> 
> "Not urgent, more of a cosmetic thing that was found while debugging and
> issue and pondering why the FPU flag is set on these threads."

Duh, I stopped reading at the --- just like a patch tool.. :/

> So it's not really a performance issue, it was just something odd that
> got me scratching my head when debugging another issue and poking at
> the flags.
> 
> Want a resend of it, or will you just augment the commit message?

I think tglx typically takes fpu patches, but sure can do.

Re: [PATCH] x86/fpu: don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[Jens Axboe]

On 1/24/23 9:23 AM, Peter Zijlstra wrote:
> On Tue, Jan 24, 2023 at 09:06:08AM -0700, Jens Axboe wrote:
>> On 1/24/23 8:40 AM, Peter Zijlstra wrote:
>>> On Tue, Jan 24, 2023 at 08:23:20AM -0700, Jens Axboe wrote:
>>>> We don't set it on PF_KTHREAD threads as they never return to userspace,
>>>> and PF_IO_WORKER threads are identical in that regard. As they keep
>>>> running in the kernel until they die, skip setting the FPU flag on them.
>>>
>>> No objection to the actual patch; but this changelog fails to tell us
>>> why this is important.
>>>
>>> What made you get up and write this patch :-) Presumably this is a
>>> performance issue? If so, can you quantify how much?
>>
>> You snipped the part where that was explained, but arguably that should
>> probably go into the commit message itself:
>>
>> "Not urgent, more of a cosmetic thing that was found while debugging and
>> issue and pondering why the FPU flag is set on these threads."
> 
> Duh, I stopped reading at the --- just like a patch tool.. :/

Yeah... Half of that should've been in the commit message, my bad.

>> So it's not really a performance issue, it was just something odd that
>> got me scratching my head when debugging another issue and poking at
>> the flags.
>>
>> Want a resend of it, or will you just augment the commit message?
> 
> I think tglx typically takes fpu patches, but sure can do.

Thanks!

-- 
Jens Axboe

[tip: x86/fpu] x86/fpu: Don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

[tip-bot2 for Jens Axboe]

The following commit has been merged into the x86/fpu branch of tip:

Commit-ID:     cb3ea4b7671b7cfbac3ee609976b790aebd0bbda
Gitweb:        https://git.kernel.org/tip/cb3ea4b7671b7cfbac3ee609976b790aebd0bbda
Author:        Jens Axboe <axboe@kernel.dk>
AuthorDate:    Tue, 24 Jan 2023 08:23:20 -07:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Wed, 25 Jan 2023 12:35:15 +01:00

x86/fpu: Don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads

We don't set it on PF_KTHREAD threads as they never return to userspace,
and PF_IO_WORKER threads are identical in that regard. As they keep
running in the kernel until they die, skip setting the FPU flag on them.

More of a cosmetic thing that was found while debugging and
issue and pondering why the FPU flag is set on these threads.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/560c844c-f128-555b-40c6-31baff27537f@kernel.dk
---
 arch/x86/include/asm/fpu/sched.h | 2 +-
 arch/x86/kernel/fpu/context.h    | 2 +-
 arch/x86/kernel/fpu/core.c       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/fpu/sched.h b/arch/x86/include/asm/fpu/sched.h
index b2486b2..c2d6cd7 100644
--- a/arch/x86/include/asm/fpu/sched.h
+++ b/arch/x86/include/asm/fpu/sched.h
@@ -39,7 +39,7 @@ extern void fpu_flush_thread(void);
 static inline void switch_fpu_prepare(struct fpu *old_fpu, int cpu)
 {
 	if (cpu_feature_enabled(X86_FEATURE_FPU) &&
-	    !(current->flags & PF_KTHREAD)) {
+	    !(current->flags & (PF_KTHREAD | PF_IO_WORKER))) {
 		save_fpregs_to_fpstate(old_fpu);
 		/*
 		 * The save operation preserved register state, so the
diff --git a/arch/x86/kernel/fpu/context.h b/arch/x86/kernel/fpu/context.h
index 958accf..9fcfa5c 100644
--- a/arch/x86/kernel/fpu/context.h
+++ b/arch/x86/kernel/fpu/context.h
@@ -57,7 +57,7 @@ static inline void fpregs_restore_userregs(void)
 	struct fpu *fpu = &current->thread.fpu;
 	int cpu = smp_processor_id();
 
-	if (WARN_ON_ONCE(current->flags & PF_KTHREAD))
+	if (WARN_ON_ONCE(current->flags & (PF_KTHREAD | PF_IO_WORKER)))
 		return;
 
 	if (!fpregs_state_valid(fpu, cpu)) {
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 9baa89a..2babc53 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -426,7 +426,7 @@ void kernel_fpu_begin_mask(unsigned int kfpu_mask)
 
 	this_cpu_write(in_kernel_fpu, true);
 
-	if (!(current->flags & PF_KTHREAD) &&
+	if (!(current->flags & (PF_KTHREAD | PF_IO_WORKER)) &&
 	    !test_thread_flag(TIF_NEED_FPU_LOAD)) {
 		set_thread_flag(TIF_NEED_FPU_LOAD);
 		save_fpregs_to_fpstate(&current->thread.fpu);