From: Waiman Long <longman@redhat.com>
To: David Laight <david.laight.linux@gmail.com>
Cc: 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>
Subject: Re: [PATCH v4 next 1/9] locking/osq_lock: Add some comments about how it works
Date: Wed, 9 Sep 2026 10:57:58 -0400 [thread overview]
Message-ID: <f702db47-7039-4bef-9267-ea83c0cb0b1b@redhat.com> (raw)
In-Reply-To: <20260907084133.3696-2-david.laight.linux@gmail.com>
On 9/7/26 4:41 AM, David Laight wrote:
> 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.
Typo: "ponter" -> "pointer".
This description seems to describe the optimistic_spin_node structure
after patch 2. So should you swap patch 1 and 2 to be more accurate?
Saying that 'pointers' can either be the osq_node address or the
associated CPU numbers is a bit vague. next is the osq_node address and
prev is the offset'ed CPU numbers. It is not really either one or the
other. Other than that, the description looks good.
Cheers,
Longman
next prev parent reply other threads:[~2026-09-09 14:58 UTC|newest]
Thread overview: 26+ 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 [this message]
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-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-07 8:41 ` [PATCH v4 next 4/9] locking/osq_lock: Delete 'fast path' code from osq_unlock() David Laight
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-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
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=f702db47-7039-4bef-9267-ea83c0cb0b1b@redhat.com \
--to=longman@redhat.com \
--cc=boqun@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®