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 6/9] locking/osq: Use cpu number for 'next' pointer
Date: Mon, 7 Sep 2026 09:41:30 +0100 [thread overview]
Message-ID: <20260907084133.3696-7-david.laight.linux@gmail.com> (raw)
In-Reply-To: <20260907084133.3696-1-david.laight.linux@gmail.com>
There is only one write done through node->next (setting prev)
when 'node' is being removed.
So the code can consistently use the cpu numbers pretty much
throughout (this was suggested by Linux a while back).
This reduces struct optimistic_spin_node to 8 bytes.
This is currently padded out to a cache line which is silly.
Change to be __aligned(8) so that it isn't split between cache lines.
Accesses to 'other cpu' data are very limited and only happen during
the enque and deque operation.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
kernel/locking/osq_lock.c | 43 ++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 2f92d3d63da9..0f68ee017b54 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -24,21 +24,21 @@
* 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
+ * The 'next' pointer of the tail must be zero, all the other 'next' pointers
+ * must either be valid or transiently zero.
+ * The 'prev' pointer is zero unless the node is waiting for the lock, when
+ * waiting it may refer to the wrong node (node->prev->next != node).
+ * The 'prev' value is only needed 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 {
- struct optimistic_spin_node *next;
- int prev; /* CPU number offset by 1 */
-};
+ int next; /* CPU number offset by 1, 0 if no next */
+ int prev; /* CPU number offset by 1, 0 if lock held */
+} __aligned(8);
-static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node, osq_node);
+static DEFINE_PER_CPU(struct optimistic_spin_node, osq_node);
/*
* We use the value 0 to represent "no CPU", thus the encoded value
@@ -72,11 +72,12 @@ static inline struct optimistic_spin_node *decode_cpu(int encoded_cpu_val)
* When a lock request is being cancelled the caller needs 'next' to
* set node->prev->next = next.
*/
-static inline struct optimistic_spin_node *
+static inline int
osq_unlink_from_next(struct optimistic_spin_queue *lock, int prev)
{
int curr = encode_cpu(smp_processor_id());
- struct optimistic_spin_node *node, *next;
+ struct optimistic_spin_node *node;
+ int next;
for (;;) {
int tail = atomic_read(&lock->tail);
@@ -88,9 +89,9 @@ osq_unlink_from_next(struct optimistic_spin_queue *lock, int prev)
* If prev was spinning in this loop it can continue.
*
* Since we are the tail of the list, node->next
- * must be NULL.
+ * must be zero.
*/
- return NULL;
+ return 0;
}
node = this_cpu_ptr(&osq_node);
@@ -104,7 +105,7 @@ osq_unlink_from_next(struct optimistic_spin_queue *lock, int prev)
* the concurrent unqueue completes.
*/
if (node->next) {
- next = xchg(&node->next, NULL);
+ next = xchg(&node->next, 0);
if (next)
break;
}
@@ -118,16 +119,16 @@ osq_unlink_from_next(struct optimistic_spin_queue *lock, int prev)
* When called while unqueueing in osq_lock() this completes the
* backwards link, the forwards link is done by the caller.
*/
- WRITE_ONCE(next->prev, prev);
+ WRITE_ONCE(decode_cpu(next)->prev, prev);
return next;
}
bool osq_lock(struct optimistic_spin_queue *lock)
{
- struct optimistic_spin_node *node, *prev_ptr, *next;
+ struct optimistic_spin_node *node, *prev_ptr;
int curr = encode_cpu(smp_processor_id());
- int prev;
+ int next, prev;
/*
* We need both ACQUIRE (pairs with corresponding RELEASE in
@@ -155,7 +156,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
*/
smp_wmb();
- WRITE_ONCE(prev_ptr->next, node);
+ WRITE_ONCE(prev_ptr->next, curr);
/*
* Normally @prev is untouchable after the above store; because at that
@@ -191,8 +192,8 @@ bool osq_lock(struct optimistic_spin_queue *lock)
prev_ptr = decode_cpu(prev);
- if (data_race(prev_ptr->next) == node &&
- cmpxchg(&prev_ptr->next, node, NULL) == node)
+ if (data_race(prev_ptr->next) == curr &&
+ cmpxchg(&prev_ptr->next, curr, 0) == curr)
break;
/*
--
2.39.5
next prev parent 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 ` [PATCH v4 next 1/9] locking/osq_lock: Add some comments about how it works David Laight
2026-09-09 14:57 ` 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 ` David Laight [this message]
2026-11-06 10:25 ` [tip: locking/core] locking/osq: Use CPU number for 'next' pointer 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-7-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.