public inbox for linux-kernel@vger.kernel.org
 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>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: [PATCH 2/6] timers/migration: Remove locking on group connection
Date: Fri, 24 Oct 2025 15:25:32 +0200	[thread overview]
Message-ID: <20251024132536.39841-3-frederic@kernel.org> (raw)
In-Reply-To: <20251024132536.39841-1-frederic@kernel.org>

Initializing the tmc's group, the group's number of children and the
group's parent can all be done without locking because:

1) Reading the group's parent and its groupmask is done locklessly.

2) The connections prepared for a given CPU hierarchy are visible to the
   target CPU once online, thanks to the CPU hotplug enforced memory
   ordering.

3) In case of a newly created upper level, the new root and its
   connections/initializations are made visible by the CPU which made
   the connections. When that CPUs goes idle in the future, the new link
   is published by tmigr_inactive_up() through the atomic RmW on
   ->migr_state.

4) If CPUs were still walking up the active hierarchy, they could observe
   the new root earlier. In this case the ordering is enforced by an
   early initialization of the group mask and by barriers that maintain
   address dependency as explained in:

    b729cc1ec21a ("timers/migration: Fix another race between hotplug and idle entry/exit")
	de3ced72a792 ("timers/migration: Enforce group initialization visibility to tree walkers")

5) Timers are propagated by a chain of group locking from the bottom to
   the top. And while doing so, the tree also propagates groups links
   and initializations. Therefore remote expiration, which also relies
   on group locking, will observe those links and initialization while
   holding the root lock before walking the tree remotely and update
   remote timers. This is especially important for migrators in the
   active hierarchy that may observe the new root early.

Therefore the locking is unecesserary at initialization. If anything,
it just brings confusion. Remove it.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 kernel/time/timer_migration.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
index 1e371f1fdc86..5f8aef94ca0f 100644
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -1573,9 +1573,6 @@ static void tmigr_connect_child_parent(struct tmigr_group *child,
 {
 	struct tmigr_walk data;
 
-	raw_spin_lock_irq(&child->lock);
-	raw_spin_lock_nested(&parent->lock, SINGLE_DEPTH_NESTING);
-
 	if (activate) {
 		/*
 		 * @child is the old top and @parent the new one. In this
@@ -1596,9 +1593,6 @@ static void tmigr_connect_child_parent(struct tmigr_group *child,
 	 */
 	smp_store_release(&child->parent, parent);
 
-	raw_spin_unlock(&parent->lock);
-	raw_spin_unlock_irq(&child->lock);
-
 	trace_tmigr_connect_child_parent(child);
 
 	if (!activate)
@@ -1695,13 +1689,9 @@ static int tmigr_setup_groups(unsigned int cpu, unsigned int node)
 		if (i == 0) {
 			struct tmigr_cpu *tmc = per_cpu_ptr(&tmigr_cpu, cpu);
 
-			raw_spin_lock_irq(&group->lock);
-
 			tmc->tmgroup = group;
 			tmc->groupmask = BIT(group->num_children++);
 
-			raw_spin_unlock_irq(&group->lock);
-
 			trace_tmigr_connect_cpu_parent(tmc);
 
 			/* There are no children that need to be connected */
-- 
2.51.0


  parent reply	other threads:[~2025-10-24 13:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-24 13:25 [PATCH 0/6] timers/migration: Fix NUMA trees + cleanups Frederic Weisbecker
2025-10-24 13:25 ` [PATCH 1/6] timers/migration: Convert "while" loops to use "for" Frederic Weisbecker
2025-11-01 19:41   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2025-10-24 13:25 ` Frederic Weisbecker [this message]
2025-11-01 19:41   ` [tip: timers/core] timers/migration: Remove locking on group connection tip-bot2 for Frederic Weisbecker
2025-10-24 13:25 ` [PATCH 3/6] timers/migration: Fix imbalanced NUMA trees Frederic Weisbecker
2025-11-01 19:41   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2025-10-24 13:25 ` [PATCH 4/6] timers/migration: Assert that hotplug preparing CPU is part of stable active hierarchy Frederic Weisbecker
2025-11-01 19:41   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2025-10-24 13:25 ` [PATCH 5/6] timers/migration: Remove unused "cpu" parameter from tmigr_get_group() Frederic Weisbecker
2025-11-01 19:41   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2025-10-24 13:25 ` [PATCH 6/6] timers/migration: Remove dead code handling idle CPU checking for remote timers Frederic Weisbecker
2025-11-01 19:41   ` [tip: timers/core] " tip-bot2 for 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=20251024132536.39841-3-frederic@kernel.org \
    --to=frederic@kernel.org \
    --cc=anna-maria@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --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