From: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Marco Crivellari <marco.crivellari@suse.com>,
Waiman Long <llong@redhat.com>,
cgroups@vger.kernel.org
Subject: [PATCH 1/2] genirq: Fix IRQ threads affinity VS cpuset isolated partitions
Date: Tue, 18 Nov 2025 15:30:51 +0100 [thread overview]
Message-ID: <20251118143052.68778-2-frederic@kernel.org> (raw)
In-Reply-To: <20251118143052.68778-1-frederic@kernel.org>
When a cpuset isolated partition is created / updated or destroyed,
the IRQ threads are affine blindly to all the non-isolated CPUs. And
this happens without taking into account the IRQ thread initial
affinity that becomes ignored.
For example in a system with 8 CPUs, if an IRQ and its kthread are
initially affine to CPU 5, creating an isolated partition with only
CPU 2 inside will eventually end up affining the IRQ kthread to all
CPUs but CPU 2 (that is CPUs 0,1,3-7), losing the kthread preference for
CPU 5.
Besides the blind re-affinity, this doesn't take care of the actual
low level interrupt which isn't migrated. As of today the only way to
isolate non managed interrupts, along with their kthreads, is to
overwrite their affinity separately, for example through /proc/irq/
To avoid doing that manually, future development should focus on
updating the IRQs affinity whenever cpuset isolated partitions are
updated.
In the meantime, cpuset shouldn't fiddle with IRQ threads directly.
To prevent from that, set the PF_NO_SETAFFINITY flag to them.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
kernel/irq/manage.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 400856abf672..76e2cbe21d1f 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -176,7 +176,7 @@ bool irq_can_set_affinity_usr(unsigned int irq)
}
/**
- * irq_set_thread_affinity - Notify irq threads to adjust affinity
+ * irq_thread_update_affinity - Notify irq threads to adjust affinity
* @desc: irq descriptor which has affinity changed
*
* Just set IRQTF_AFFINITY and delegate the affinity setting to the
@@ -184,7 +184,7 @@ bool irq_can_set_affinity_usr(unsigned int irq)
* we hold desc->lock and this code can be called from hard interrupt
* context.
*/
-static void irq_set_thread_affinity(struct irq_desc *desc)
+static void irq_thread_update_affinity(struct irq_desc *desc)
{
struct irqaction *action;
@@ -283,7 +283,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask,
fallthrough;
case IRQ_SET_MASK_OK_NOCOPY:
irq_validate_effective_affinity(data);
- irq_set_thread_affinity(desc);
+ irq_thread_update_affinity(desc);
ret = 0;
}
@@ -1035,8 +1035,16 @@ static void irq_thread_check_affinity(struct irq_desc *desc, struct irqaction *a
set_cpus_allowed_ptr(current, mask);
free_cpumask_var(mask);
}
+
+static inline void irq_thread_set_affinity(struct task_struct *t,
+ struct irq_desc *desc)
+{
+ kthread_bind_mask(t, irq_data_get_effective_affinity_mask(&desc->irq_data));
+}
#else
static inline void irq_thread_check_affinity(struct irq_desc *desc, struct irqaction *action) { }
+static inline void irq_thread_set_affinity(struct task_struct *t,
+ struct irq_desc *desc) { }
#endif
static int irq_wait_for_interrupt(struct irq_desc *desc,
@@ -1221,6 +1229,7 @@ static void wake_up_and_wait_for_irq_thread_ready(struct irq_desc *desc,
if (!action || !action->thread)
return;
+ irq_thread_set_affinity(action->thread, desc);
wake_up_process(action->thread);
wait_event(desc->wait_for_threads,
test_bit(IRQTF_READY, &action->thread_flags));
@@ -1405,16 +1414,7 @@ setup_irq_thread(struct irqaction *new, unsigned int irq, bool secondary)
* references an already freed task_struct.
*/
new->thread = get_task_struct(t);
- /*
- * Tell the thread to set its affinity. This is
- * important for shared interrupt handlers as we do
- * not invoke setup_affinity() for the secondary
- * handlers as everything is already set up. Even for
- * interrupts marked with IRQF_NO_BALANCE this is
- * correct as we want the thread to move to the cpu(s)
- * on which the requesting code placed the interrupt.
- */
- set_bit(IRQTF_AFFINITY, &new->thread_flags);
+
return 0;
}
--
2.51.0
next prev parent reply other threads:[~2025-11-18 14:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-18 14:30 [PATCH 0/2] genirq: Fix IRQ threads VS cpuset Frederic Weisbecker
2025-11-18 14:30 ` Frederic Weisbecker [this message]
2025-11-18 15:26 ` [tip: irq/core] genirq: Fix interrupt threads affinity vs. cpuset isolated partitions tip-bot2 for Frederic Weisbecker
2025-11-18 16:27 ` [PATCH 1/2] genirq: Fix IRQ threads affinity VS " Waiman Long
2025-11-18 17:23 ` Thomas Gleixner
2025-11-18 17:29 ` Waiman Long
2025-11-20 11:51 ` Marek Szyprowski
2025-11-20 13:20 ` Frederic Weisbecker
2025-11-20 15:00 ` Thomas Gleixner
2025-11-20 15:50 ` Frederic Weisbecker
2025-11-20 19:09 ` Thomas Gleixner
2025-11-20 16:34 ` Marek Szyprowski
2025-11-20 13:45 ` Thomas Gleixner
2025-11-18 14:30 ` [PATCH 2/2] genirq: Remove cpumask availability check on kthread affinity setting Frederic Weisbecker
2025-11-18 15:26 ` [tip: irq/core] " tip-bot2 for Frederic Weisbecker
2025-11-18 15:14 ` [PATCH 0/2] genirq: Fix IRQ threads VS cpuset Thomas Gleixner
2025-11-18 17:44 ` Frederic Weisbecker
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=20251118143052.68778-2-frederic@kernel.org \
--to=frederic@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llong@redhat.com \
--cc=marco.crivellari@suse.com \
--cc=tglx@linutronix.de \
/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