From: 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 <loaor.shao@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Cc: David Laight <david.laight.linux@gmail.com>
Subject: [PATCH v3 next 0/5] locking/osq_lock: Optimisations to osq_lock code
Date: Fri, 6 Mar 2026 22:51:45 +0000 [thread overview]
Message-ID: <20260306225150.93178-1-david.laight.linux@gmail.com> (raw)
From: David Laight <david.laight.linux@gmail.com>
This is a slightly edited copy of v2 from 2 years ago.
I've re-read the comments (on v1 and v2).
Patch #3 now unconditionally calls decode_cpu() when stabilizing @prev
(I'm not at all sure the cpu number can ever be unchanged.)
Patch #5 now converts almost all the cpu numbers to 'unsigned int'.
Fot patch #2 I've found a note that:
kernel test robot noticed a 10.7% improvement of stress-ng.netlink-task.ops_per_sec
Notes from v2:
Patch #1 is the node->locked part of v1's patch #2.
Patch #2 removes the pretty much guaranteed cache line reload getting
the cpu number (from node->prev) for the vcpu_is_preempted() check.
It is (basically) the old #5 with the addition of a READ_ONCE()
and leaving the '+ 1' offset (for patch 3).
Patch #3 ends up removing both node->cpu and node->prev.
This saves issues initialising node->cpu.
Basically node->cpu was only ever read as node->prev->cpu in the unqueue code.
Most of the time it is the value read from lock->tail that was used to
obtain 'prev' in the first place.
The only time it is different is in the unlock race path where 'prev'
is re-read from node->prev - updated right at the bottom of osq_lock().
So the updated node->prev_cpu can used (and prev obtained from it) without
worrying about only one of node->prev and node->prev-cpu being updated.
Linus did suggest just saving the cpu numbers instead of pointers.
It actually works for 'prev' but not 'next'.
Patch #4 removes the unnecessary node->next = NULL
assignment from the top of osq_lock().
Patch #5 just stops gcc using two separate instructions to decrement
the offset cpu number and then convert it to 64 bits.
Linus got annoyed with it, and I'd spotted it as well.
I don't seem to be able to get gcc to convert __per_cpu_offset[cpu - 1]
to (__per_cpu_offset - 1)[cpu] (cpu is offset by one) but, in any case,
it would still need zero extending in the common case.
David Laight (5):
Defer clearing node->locked until the slow osq_lock() path.
Optimise vcpu_is_preempted() check.
Use node->prev_cpu instead of saving node->prev.
Optimise decode_cpu() and per_cpu_ptr().
Avoid writing to node->next in the osq_lock() fast path.
kernel/locking/osq_lock.c | 56 +++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 29 deletions(-)
--
2.39.5
next reply other threads:[~2026-03-06 22:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 22:51 david.laight.linux [this message]
2026-03-06 22:51 ` [PATCH v3 next 1/5] Only clear node->locked in the slow osq_lock() path david.laight.linux
2026-03-06 23:01 ` David Laight
2026-03-06 22:51 ` [PATCH v3 next 2/5] Optimise vcpu_is_preempted() check david.laight.linux
2026-03-06 23:01 ` David Laight
2026-03-06 23:03 ` David Laight
2026-03-06 22:51 ` [PATCH v3 next 3/5] Use node->prev_cpu instead of saving node->prev david.laight.linux
2026-03-06 23:01 ` David Laight
2026-03-06 23:03 ` David Laight
2026-03-06 22:51 ` [PATCH v3 next 4/5] Optimise decode_cpu() and per_cpu_ptr() david.laight.linux
2026-03-06 23:01 ` David Laight
2026-03-06 23:03 ` David Laight
2026-03-06 22:51 ` [PATCH v3 next 5/5] Avoid writing to node->next in the osq_lock() fast path david.laight.linux
2026-03-06 23:04 ` David Laight
2026-03-07 0:06 ` Linus Torvalds
2026-03-07 11:32 ` David Laight
2026-03-11 19:27 ` Waiman Long
2026-03-11 19:40 ` Waiman Long
2026-03-11 21:50 ` David Laight
2026-03-06 22:59 ` [PATCH v3 next 0/5] locking/osq_lock: Optimisations to osq_lock code 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=20260306225150.93178-1-david.laight.linux@gmail.com \
--to=david.laight.linux@gmail.com \
--cc=boqun@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loaor.shao@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox