From: Peter Zijlstra <peterz@infradead.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Waiman Long <longman@redhat.com>, 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>
Subject: Re: [PATCH v4 next 2/9] locking/osq_lock: Save the cpu number for 'prev' not the node address
Date: Tue, 15 Sep 2026 12:26:02 +0200 [thread overview]
Message-ID: <20260915102602.GC4121620@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260915083340.GY4121339@noisy.programming.kicks-ass.net>
On Tue, Sep 15, 2026 at 10:33:40AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 07, 2026 at 09:41:26AM +0100, David Laight wrote:
> > The cpu number of node->prev is needed for both the vcpu_is_preempted()
> > test and to update lock->tail.
> > This saves reading the cache line for the other cpu's per-cpu data.
> >
> > The cpu member of optimistic_spin_node is no longer needed.
> >
> > Merges patches 2 and 3 from v3.
> >
> > Signed-off-by: David Laight <david.laight.linux@gmail.com>
> > ---
> > kernel/locking/osq_lock.c | 33 ++++++++++++++-------------------
> > 1 file changed, 14 insertions(+), 19 deletions(-)
> >
> > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> > index b17aa704c449..01988d00c480 100644
> > --- a/kernel/locking/osq_lock.c
> > +++ b/kernel/locking/osq_lock.c
> > @@ -34,9 +34,9 @@
> > */
> >
> > struct optimistic_spin_node {
> > - struct optimistic_spin_node *next, *prev;
> > + struct optimistic_spin_node *next;
> > int locked; /* 1 if lock acquired */
> > - int cpu; /* encoded CPU # + 1 value */
> > + int prev; /* CPU number offset by 1 */
> > };
> >
> > static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node, osq_node);
>
> > @@ -114,13 +109,12 @@ osq_wait_next(struct optimistic_spin_queue *lock,
> > bool osq_lock(struct optimistic_spin_queue *lock)
> > {
> > struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
> > - struct optimistic_spin_node *prev, *next;
> > + struct optimistic_spin_node *prev_ptr, *next;
> > int curr = encode_cpu(smp_processor_id());
> > - int old;
> > + int prev;
>
> I'm not a fan in the asymmetry of the naming, that is very confusing at
> best.
Maybe something like so?
---
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -34,9 +34,9 @@
*/
struct optimistic_spin_node {
- struct optimistic_spin_node *next, *prev;
+ struct optimistic_spin_node *next;
int locked; /* 1 if lock acquired */
- int cpu; /* encoded CPU # + 1 value */
+ int prev_cpu; /* CPU number offset by 1 */
};
static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node, osq_node);
@@ -50,11 +50,6 @@ static inline int encode_cpu(int cpu_nr)
return cpu_nr + 1;
}
-static inline int node_cpu(struct optimistic_spin_node *node)
-{
- return node->cpu - 1;
-}
-
static inline struct optimistic_spin_node *decode_cpu(int encoded_cpu_val)
{
int cpu_nr = encoded_cpu_val - 1;
@@ -116,11 +111,10 @@ bool osq_lock(struct optimistic_spin_que
struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
struct optimistic_spin_node *prev, *next;
int curr = encode_cpu(smp_processor_id());
- int old;
+ int prev_cpu;
node->locked = 0;
node->next = NULL;
- node->cpu = curr;
/*
* We need both ACQUIRE (pairs with corresponding RELEASE in
@@ -128,12 +122,12 @@ bool osq_lock(struct optimistic_spin_que
* the node fields we just initialised) semantics when updating
* the lock tail.
*/
- old = atomic_xchg(&lock->tail, curr);
- if (old == OSQ_UNLOCKED_VAL)
+ prev_cpu = atomic_xchg(&lock->tail, curr);
+ if (prev_cpu == OSQ_UNLOCKED_VAL)
return true;
- prev = decode_cpu(old);
- node->prev = prev;
+ prev = decode_cpu(prev_cpu);
+ node->prev_cpu = prev_cpu;
/*
* osq_lock() unqueue
@@ -165,7 +159,7 @@ bool osq_lock(struct optimistic_spin_que
* polling, be careful.
*/
if (smp_cond_load_relaxed(&node->locked, VAL || need_resched() ||
- vcpu_is_preempted(node_cpu(node->prev))))
+ vcpu_is_preempted(node->prev_cpu - 1)))
return true;
/* unqueue */
@@ -200,7 +194,8 @@ bool osq_lock(struct optimistic_spin_que
* 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_cpu = READ_ONCE(node->prev_cpu);
+ prev = decode_cpu(prev_cpu);
}
/*
@@ -210,7 +205,7 @@ bool osq_lock(struct optimistic_spin_que
* back to @prev.
*/
- next = osq_wait_next(lock, node, prev->cpu);
+ next = osq_wait_next(lock, node, prev_cpu);
if (!next)
return false;
@@ -222,7 +217,7 @@ bool osq_lock(struct optimistic_spin_que
* it will wait in Step-A.
*/
- WRITE_ONCE(next->prev, prev);
+ WRITE_ONCE(next->prev_cpu, prev_cpu);
WRITE_ONCE(prev->next, next);
return false;
next prev parent reply other threads:[~2026-09-15 10:26 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 [this message]
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=20260915102602.GC4121620@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=boqun@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--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.