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 = ¤t->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(¤t->thread.fpu);
--
Jens Axboe
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?
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
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.
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
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 = ¤t->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(¤t->thread.fpu);
© 2016 - 2025 Red Hat, Inc.