All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Waiman Long <longman@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Yafang Shao <laoar.shao@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: David Laight <david.laight.linux@gmail.com>
Subject: [PATCH v4 next 1/9] locking/osq_lock: Add some comments about how it works
Date: Mon,  7 Sep 2026 09:41:25 +0100	[thread overview]
Message-ID: <20260907084133.3696-2-david.laight.linux@gmail.com> (raw)
In-Reply-To: <20260907084133.3696-1-david.laight.linux@gmail.com>

No code changes, just some extra explanations.

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
 kernel/locking/osq_lock.c | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index b4233dc2c2b0..b17aa704c449 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -4,12 +4,33 @@
 #include <linux/osq_lock.h>
 
 /*
- * An MCS like lock especially tailored for optimistic spinning for sleeping
- * lock implementations (mutex, rwsem, etc).
+ * An MCS like spin lock especially tailored for optimistic spinning for
+ * sleeping lock implementations (mutex, rwsem, etc).
+ * Each CPU spins on a local variable to avoid cache-line bounces.
  *
- * Using a single mcs node per CPU is safe because sleeping locks should not be
+ * The CPU that holds the osq_lock checks the mutex/rwsem, the other CPU spin
+ * in osq_lock() until either the osq_lock is obtained or the scheduler
+ * requests the process be preempted.
+ *
+ * Using a single osq node per CPU is safe because sleeping locks should not be
  * called from interrupt context and we have preemption disabled while
  * spinning.
+ *
+ * The osq_nodes for the spinning CPU are put on a double-linked (non circular)
+ * list. The list 'pointers' can either be the address of the osq_node or the
+ * associated CPU number, the CPU numbers are offset by one so that zero can
+ * be used like a NULL ponter.
+ * The mutex/rwsem contains a pointer (CPU number) to the tail of the list.
+ * There is no equivalent pointer to the list head - the 'head' is the
+ * osq_node of the CPU that acquired the osq lock.
+ *
+ * The 'next' pointer of the tail must be NULL, all the other 'next' pointers
+ * must either be valid or transiently NULL.
+ * The 'prev' pointers only need to be valid when node->prev makes sense and,
+ * even then, can be transiently invalid (ie refer to the wrong node).
+ * They are only used for the node->prev->next = node->next update when
+ * 'node' is being removed. Atomically checking node->prev->next == node
+ * ensures the list doesn't get corrupted.
  */
 
 struct optimistic_spin_node {
-- 
2.39.5


  reply	other threads:[~2026-09-07  8:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07  8:41 [PATCH v4 next 0/9] locking/osq_lock: Optimisations to osq_lock code David Laight
2026-09-07  8:41 ` David Laight [this message]
2026-09-09 14:57   ` [PATCH v4 next 1/9] locking/osq_lock: Add some comments about how it works Waiman Long
2026-09-07  8:41 ` [PATCH v4 next 2/9] locking/osq_lock: Save the cpu number for 'prev' not the node address David Laight
2026-09-09 17:36   ` Waiman Long
2026-09-15  8:33   ` Peter Zijlstra
2026-09-15 10:26     ` Peter Zijlstra
2026-09-15 11:11       ` David Laight
2026-09-15 17:27       ` Waiman Long
2026-11-06 10:25   ` [tip: locking/core] locking/osq: Save the CPU number for 'prev', " tip-bot2 for David Laight
2026-09-07  8:41 ` [PATCH v4 next 3/9] locking/osq_lock: Set prev_cpu=0 instead of locked=1 David Laight
2026-09-09 18:01   ` Waiman Long
2026-09-09 18:52     ` David Laight
2026-09-14 12:01       ` Peter Zijlstra
2026-09-14 13:10         ` David Laight
2026-09-14 12:03   ` Peter Zijlstra
2026-09-14 13:08     ` David Laight
2026-09-15  8:40       ` Peter Zijlstra
2026-09-15 10:14         ` David Laight
2026-09-15  8:50   ` Peter Zijlstra
2026-09-15 10:20     ` David Laight
2026-09-15 10:40       ` Peter Zijlstra
2026-09-15 13:13   ` Peter Zijlstra
2026-09-15 13:15     ` Peter Zijlstra
2026-09-15 13:55       ` David Laight
2026-09-15 14:01         ` Peter Zijlstra
2026-09-15 17:47           ` David Laight
2026-09-16  8:08             ` Peter Zijlstra
2026-11-06 10:25   ` [tip: locking/core] locking/osq: " tip-bot2 for David Laight
2026-09-07  8:41 ` [PATCH v4 next 4/9] locking/osq_lock: Delete 'fast path' code from osq_unlock() David Laight
2026-09-15 14:15   ` Peter Zijlstra
2026-09-16 10:56     ` Peter Zijlstra
2026-09-07  8:41 ` [PATCH v4 next 5/9] locking/osq_lock: Avoid writing to node->next in the osq_lock() fast path David Laight
2026-09-07  8:41 ` [PATCH v4 next 6/9] locking/osq: Use cpu number for 'next' pointer David Laight
2026-11-06 10:25   ` [tip: locking/core] locking/osq: Use CPU " tip-bot2 for David Laight
2026-09-07  8:41 ` [PATCH v4 next 7/9] locking/osq: Use 'unsigned int' for next/prev/tail David Laight
2026-09-07  8:41 ` [PATCH v4 next 8/9] locking/osq: inline encode_cpu() and rename decode_cpu() David Laight
2026-09-07  8:41 ` [PATCH v4 next 9/9] locking/osq_lock: Swap next<->prev and tail<->head David Laight
2026-09-07 16:08 ` [PATCH v4 next 0/9] locking/osq_lock: Optimisations to osq_lock code Linus Torvalds
2026-09-07 17:27   ` David Laight
2026-09-09 14:15     ` Haakon Bugge
2026-09-09 19:09       ` David Laight
2026-09-09 20:14       ` Waiman Long
2026-09-09 20:33         ` Waiman Long
2026-09-10  9:45           ` Haakon Bugge
2026-09-10 11:00             ` David Laight
2026-09-10 11:31               ` Haakon Bugge
2026-09-10 12:05                 ` David Laight
2026-09-10 15:30                   ` Haakon Bugge
2026-09-10 16:22                     ` Waiman Long
2026-09-11 17:15                     ` David Laight
2026-09-14 11:46                       ` Haakon Bugge
2026-09-14 13:24                         ` David Laight
2026-09-11 10:08                 ` David Laight

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=20260907084133.3696-2-david.laight.linux@gmail.com \
    --to=david.laight.linux@gmail.com \
    --cc=boqun@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.