linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Marco Crivellari <marco.crivellari@suse.com>,
	Waiman Long <llong@redhat.com>,
	cgroups@vger.kernel.org
Subject: [PATCH 2/3 v3] genirq: Fix interrupt threads affinity vs. cpuset isolated partitions
Date: Fri, 21 Nov 2025 15:34:59 +0100	[thread overview]
Message-ID: <20251121143500.42111-3-frederic@kernel.org> (raw)
In-Reply-To: <20251121143500.42111-1-frederic@kernel.org>

When a cpuset isolated partition is created / updated or destroyed, the
interrupt threads are affine blindly to all the non-isolated CPUs. And this
happens without taking into account the interrupt threads initial affinity
that becomes ignored.

For example in a system with 8 CPUs, if an interrupt and its kthread are
initially affine to CPU 5, creating an isolated partition with only CPU 2
inside will eventually end up affining the interrupt 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 interrupt's affinity whenever cpuset isolated partitions are updated.

In the meantime, cpuset shouldn't fiddle with interrupt threads directly.
To prevent from that, set the PF_NO_SETAFFINITY flag to them.

Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://patch.msgid.link/20251118143052.68778-2-frederic@kernel.org
---
 kernel/irq/manage.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index c1ce30c9c3ab..98b9b8b4de27 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1408,16 +1408,23 @@ 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.
+	 * The affinity may not yet be available, but it will be once
+	 * the IRQ will be enabled. Delay and defer the actual setting
+	 * to the thread itself once it is ready to run. In the meantime,
+	 * prevent it from ever being reaffined directly by cpuset or
+	 * housekeeping. The proper way to do it is to reaffine the whole
+	 * vector.
 	 */
-	set_bit(IRQTF_AFFINITY, &new->thread_flags);
+	kthread_bind_mask(t, cpu_possible_mask);
+
+	/*
+	 * Ensure the thread adjusts the affinity once it reaches the
+	 * thread function.
+	 */
+	new->thread_flags = BIT(IRQTF_AFFINITY);
+
 	return 0;
 }
 
-- 
2.51.1


  parent reply	other threads:[~2025-11-21 14:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20251121143513eucas1p15c03a2c15aa5a0a15cc46d8f0a4e534e@eucas1p1.samsung.com>
2025-11-21 14:34 ` [PATCH 0/3 v3] genirq: Fix IRQ threads VS cpuset Frederic Weisbecker
2025-11-21 14:34   ` [PATCH 1/3 v3] genirq: Prevent from early irq thread spurious wake-ups Frederic Weisbecker
2025-11-21 19:12     ` Thomas Gleixner
2025-11-21 22:04       ` Frederic Weisbecker
2025-11-21 20:01     ` [tip: irq/core] genirq: Prevent early spurious wake-ups of interrupt threads tip-bot2 for Thomas Gleixner
2025-11-22  8:30     ` tip-bot2 for Frederic Weisbecker
2025-11-21 14:34   ` Frederic Weisbecker [this message]
2025-11-21 16:29     ` [PATCH 2/3 v3] genirq: Fix interrupt threads affinity vs. cpuset isolated partitions Waiman Long
2025-11-21 20:01     ` [tip: irq/core] " tip-bot2 for Frederic Weisbecker
2025-11-22  8:30     ` tip-bot2 for Frederic Weisbecker
2025-12-12  1:48     ` [PATCH 2/3 v3] " Chris Mason
2025-12-12  2:26       ` Thomas Gleixner
2025-12-12  4:01         ` [PATCH] genirq: Don't overwrite interrupt thread flags on setup Thomas Gleixner
2025-12-12 11:57           ` Frederic Weisbecker
2025-12-13  1:37           ` [tip: irq/urgent] " tip-bot2 for Thomas Gleixner
2025-11-21 14:35   ` [PATCH 3/3 v3] genirq: Remove cpumask availability check on kthread affinity setting Frederic Weisbecker
2025-11-21 20:01     ` [tip: irq/core] " tip-bot2 for Frederic Weisbecker
2025-11-22  8:30     ` tip-bot2 for Frederic Weisbecker
2025-11-21 20:05   ` [PATCH 0/3 v3] genirq: Fix IRQ threads VS cpuset Marek Szyprowski

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=20251121143500.42111-3-frederic@kernel.org \
    --to=frederic@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=m.szyprowski@samsung.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;
as well as URLs for NNTP newsgroup(s).