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 3/9] locking/osq_lock: Set prev_cpu=0 instead of locked=1
Date: Mon, 7 Sep 2026 09:41:27 +0100 [thread overview]
Message-ID: <20260907084133.3696-4-david.laight.linux@gmail.com> (raw)
In-Reply-To: <20260907084133.3696-1-david.laight.linux@gmail.com>
There is no need for separate prev_cpu and locked members of
struct optimistic_spin_node.
Using a single field simplifies the code slightly.
It also removes any possibility of the two values being out of sync.
When cancelling a lock request explicitly set prev_cpu to zero.
Nothing actually looks at the field, but it means that it will be zero
after a subsequent 'fast path' osq_lock() call making things consistent.
The cache line is likely to be dirty (or be dirtied) so there shouldn't
be a performance hit.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
kernel/locking/osq_lock.c | 57 +++++++++++++++++++--------------------
1 file changed, 28 insertions(+), 29 deletions(-)
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 01988d00c480..23f00c670507 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -35,7 +35,6 @@
struct optimistic_spin_node {
struct optimistic_spin_node *next;
- int locked; /* 1 if lock acquired */
int prev; /* CPU number offset by 1 */
};
@@ -113,7 +112,6 @@ bool osq_lock(struct optimistic_spin_queue *lock)
int curr = encode_cpu(smp_processor_id());
int prev;
- node->locked = 0;
node->next = NULL;
/*
@@ -158,46 +156,47 @@ bool osq_lock(struct optimistic_spin_queue *lock)
* is implemented with a monitor-wait. vcpu_is_preempted() relies on
* polling, be careful.
*/
- if (smp_cond_load_relaxed(&node->locked, VAL || need_resched() ||
- vcpu_is_preempted(node->prev - 1)))
- return true;
+ prev = smp_cond_load_relaxed(&node->prev, !VAL || need_resched() ||
+ vcpu_is_preempted(VAL - 1));
- /* unqueue */
/*
- * Step - A -- stabilize @prev
+ * Step - A
*
- * Undo our @prev->next assignment; this will make @prev's
- * unlock()/unqueue() wait for a next pointer since @lock points to us
- * (or later).
+ * Loop until either node->prev is zero (lock acquired) or we
+ * atomically change prev->next from node to NULL (stopping prev
+ * handing on the lock).
+ * Note that 'prev' can unlink itself concurrently with this
+ * test so that prev/prev_ptr can be stale, but since it
+ * is per-cpu data the memory can always be read.
*/
- for (;;) {
- /*
- * cpu_relax() below implies a compiler barrier which would
- * prevent this comparison being optimized away.
- */
+ for (;; prev = READ_ONCE(node->prev)) {
+ if (!prev)
+ /* Lock acquired */
+ return true;
+
+ prev_ptr = decode_cpu(prev);
+
if (data_race(prev_ptr->next) == node &&
cmpxchg(&prev_ptr->next, node, NULL) == node)
break;
/*
- * We can only fail the cmpxchg() racing against an unlock(),
- * in which case we should observe @node->locked becoming
- * true.
+ * 'prev' must have unlinked (or be in the process of unlinking)
+ * itself from the list.
*/
- if (smp_load_acquire(&node->locked))
- return true;
cpu_relax();
-
- /*
- * Or we race against a concurrent unqueue()'s step-B, in which
- * case its step-C will write us a new @node->prev pointer.
- */
- prev = READ_ONCE(node->prev);
- prev_ptr = decode_cpu(prev);
}
+ /*
+ * If 'prev' tries to remove itself from the list before we write
+ * a new value to prev->next it will spin in osq_wait_next().
+ */
+
+ /* Invalidate prev_cpu matching osq_unlock() */
+ node->prev = 0;
+
/*
* Step - B -- stabilize @next
*
@@ -240,11 +239,11 @@ void osq_unlock(struct optimistic_spin_queue *lock)
node = this_cpu_ptr(&osq_node);
next = xchg(&node->next, NULL);
if (next) {
- WRITE_ONCE(next->locked, 1);
+ WRITE_ONCE(next->prev, 0);
return;
}
next = osq_wait_next(lock, node, OSQ_UNLOCKED_VAL);
if (next)
- WRITE_ONCE(next->locked, 1);
+ WRITE_ONCE(next->prev, 0);
}
--
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 ` David Laight [this message]
2026-09-09 18:01 ` [PATCH v4 next 3/9] locking/osq_lock: Set prev_cpu=0 instead of locked=1 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-4-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.