From: Boqun Feng <boqun.feng@gmail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
lkmm@lists.linux.dev, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Davidlohr Bueso <dave@stgolabs.net>,
"Paul E. McKenney" <paulmck@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joelagnelf@nvidia.com>,
Uladzislau Rezki <urezki@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang@linux.dev>, Breno Leitao <leitao@debian.org>,
aeh@meta.com, netdev@vger.kernel.org, edumazet@google.com,
jhs@mojatatu.com, kernel-team@meta.com,
Erik Lundgren <elundgren@meta.com>
Subject: Re: [PATCH 0/8] Introduce simple hazard pointers for lockdep
Date: Wed, 25 Jun 2025 06:21:24 -0700 [thread overview]
Message-ID: <aFv31IIAS0fiYci5@Mac.home> (raw)
In-Reply-To: <d9c75e7c-48e2-4398-a830-9d41e7a74cc3@efficios.com>
On Wed, Jun 25, 2025 at 08:25:52AM -0400, Mathieu Desnoyers wrote:
> On 2025-06-24 23:10, Boqun Feng wrote:
> > Hi,
> >
> > This is the official first version of simple hazard pointers following
> > the RFC:
> >
> > https://lore.kernel.org/lkml/20250414060055.341516-1-boqun.feng@gmail.com/
> >
> > I rebase it onto v6.16-rc3 and hope to get more feedback this time.
> >
> > Thanks a lot for Breno Leitao to try the RFC out and share the numbers.
> >
> > I did an extra comparison this time, between the shazptr solution and
> > the synchronize_rcu_expedited() solution. In my test, during a 100 times
> > "tc qdisc replace" run:
> >
> > * IPI rate with the shazptr solution: ~14 per second per core.
> > * IPI rate with synchronize_rcu_expedited(): ~140 per second per core.
> >
> > (IPI results were from the 'CAL' line in /proc/interrupt)
> >
> > This shows that while both solutions have the similar speedup, shazptr
> > solution avoids the introduce of high IPI rate compared to
> > synchronize_rcu_expedited().
> >
> > Feedback is welcome and please let know if there is any concern or
> > suggestion. Thanks!
>
> Hi Boqun,
>
> What is unclear to me is what is the delta wrt:
>
> https://lore.kernel.org/lkml/20241008135034.1982519-4-mathieu.desnoyers@efficios.com/
>
shazptr is more close to the general hazptr I proposed earlier:
https://lore.kernel.org/lkml/20240917143402.930114-1-boqun.feng@gmail.com/
, it's aimed as a global facility therefore no hazptr_domain is needed,
plus it supports non-busy waiting synchronize_shazptr() at the
beginning.
> and whether this helper against compiler optimizations would still be needed here:
>
> https://lore.kernel.org/lkml/20241008135034.1982519-2-mathieu.desnoyers@efficios.com/
>
For the current user, no, but eventually we are going to need it.
Regards,
Boqun
> Thanks,
>
> Mathieu
>
> >
> > Regards,
> > Boqun
> >
> > --------------------------------------
> > Please find the old performance below:
> >
> > On my system (a 96-cpu VMs), the results of:
> >
> > time /usr/sbin/tc qdisc replace dev eth0 root handle 0x1: mq
> >
> > are (with lockdep enabled):
> >
> > (without the patchset)
> > real 0m1.039s
> > user 0m0.001s
> > sys 0m0.069s
> >
> > (with the patchset)
> > real 0m0.053s
> > user 0m0.000s
> > sys 0m0.051s
> >
> > i.e. almost 20x speed-up.
> >
> > Other comparisons between RCU and shazptr, the rcuscale results (using
> > default configuration from
> > tools/testing/selftests/rcutorture/bin/kvm.sh):
> >
> > RCU:
> >
> > Average grace-period duration: 7470.02 microseconds
> > Minimum grace-period duration: 3981.6
> > 50th percentile grace-period duration: 6002.73
> > 90th percentile grace-period duration: 7008.93
> > 99th percentile grace-period duration: 10015
> > Maximum grace-period duration: 142228
> >
> > shazptr:
> >
> > Average grace-period duration: 0.845825 microseconds
> > Minimum grace-period duration: 0.199
> > 50th percentile grace-period duration: 0.585
> > 90th percentile grace-period duration: 1.656
> > 99th percentile grace-period duration: 3.872
> > Maximum grace-period duration: 3049.05
> >
> > shazptr (skip_synchronize_self_scan=1, i.e. always let scan kthread to
> > wakeup):
> >
> > Average grace-period duration: 467.861 microseconds
> > Minimum grace-period duration: 92.913
> > 50th percentile grace-period duration: 440.691
> > 90th percentile grace-period duration: 460.623
> > 99th percentile grace-period duration: 650.068
> > Maximum grace-period duration: 5775.46
> >
> > shazptr_wildcard (i.e. readers always use SHAZPTR_WILDCARD):
> >
> > Average grace-period duration: 599.569 microseconds
> > Minimum grace-period duration: 1.432
> > 50th percentile grace-period duration: 582.631
> > 90th percentile grace-period duration: 781.704
> > 99th percentile grace-period duration: 1160.26
> > Maximum grace-period duration: 6727.53
> >
> > shazptr_wildcard (skip_synchronize_self_scan=1):
> >
> > Average grace-period duration: 460.466 microseconds
> > Minimum grace-period duration: 303.546
> > 50th percentile grace-period duration: 424.334
> > 90th percentile grace-period duration: 482.637
> > 99th percentile grace-period duration: 600.214
> > Maximum grace-period duration: 4126.94
> >
> > Boqun Feng (8):
> > Introduce simple hazard pointers
> > shazptr: Add refscale test
> > shazptr: Add refscale test for wildcard
> > shazptr: Avoid synchronize_shaptr() busy waiting
> > shazptr: Allow skip self scan in synchronize_shaptr()
> > rcuscale: Allow rcu_scale_ops::get_gp_seq to be NULL
> > rcuscale: Add tests for simple hazard pointers
> > locking/lockdep: Use shazptr to protect the key hashlist
> >
> > include/linux/shazptr.h | 73 +++++++++
> > kernel/locking/Makefile | 2 +-
> > kernel/locking/lockdep.c | 11 +-
> > kernel/locking/shazptr.c | 318 +++++++++++++++++++++++++++++++++++++++
> > kernel/rcu/rcuscale.c | 60 +++++++-
> > kernel/rcu/refscale.c | 77 ++++++++++
> > 6 files changed, 534 insertions(+), 7 deletions(-)
> > create mode 100644 include/linux/shazptr.h
> > create mode 100644 kernel/locking/shazptr.c
> >
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
prev parent reply other threads:[~2025-06-25 13:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 3:10 [PATCH 0/8] Introduce simple hazard pointers for lockdep Boqun Feng
2025-06-25 3:10 ` [PATCH 1/8] Introduce simple hazard pointers Boqun Feng
2025-06-25 10:00 ` Peter Zijlstra
2025-06-25 14:25 ` Mathieu Desnoyers
2025-06-25 15:05 ` Boqun Feng
2025-06-25 15:52 ` Waiman Long
2025-06-25 16:09 ` Boqun Feng
2025-06-25 17:47 ` Waiman Long
2025-06-25 3:10 ` [PATCH 2/8] shazptr: Add refscale test Boqun Feng
2025-06-25 10:02 ` Peter Zijlstra
2025-06-25 3:10 ` [PATCH 3/8] shazptr: Add refscale test for wildcard Boqun Feng
2025-06-25 10:03 ` Peter Zijlstra
2025-06-25 3:10 ` [PATCH 4/8] shazptr: Avoid synchronize_shaptr() busy waiting Boqun Feng
2025-06-25 11:40 ` Peter Zijlstra
2025-06-25 11:56 ` Peter Zijlstra
2025-06-25 13:56 ` Frederic Weisbecker
2025-06-25 15:24 ` Boqun Feng
2025-06-26 13:45 ` Frederic Weisbecker
2025-06-25 3:10 ` [PATCH 5/8] shazptr: Allow skip self scan in synchronize_shaptr() Boqun Feng
2025-06-25 3:10 ` [PATCH 6/8] rcuscale: Allow rcu_scale_ops::get_gp_seq to be NULL Boqun Feng
2025-06-25 3:11 ` [PATCH 7/8] rcuscale: Add tests for simple hazard pointers Boqun Feng
2025-06-25 3:11 ` [PATCH 8/8] locking/lockdep: Use shazptr to protect the key hashlist Boqun Feng
2025-06-25 11:59 ` Peter Zijlstra
2025-06-25 14:18 ` Boqun Feng
2025-07-10 14:06 ` Breno Leitao
2025-07-11 2:31 ` Boqun Feng
2025-06-25 12:05 ` [PATCH 0/8] Introduce simple hazard pointers for lockdep Christoph Hellwig
2025-06-25 14:08 ` Boqun Feng
2025-06-26 10:16 ` Christoph Hellwig
2025-06-26 13:45 ` Mathieu Desnoyers
2025-06-26 15:47 ` Boqun Feng
2025-06-27 2:56 ` Paul E. McKenney
2025-06-25 12:25 ` Mathieu Desnoyers
2025-06-25 13:21 ` Boqun Feng [this message]
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=aFv31IIAS0fiYci5@Mac.home \
--to=boqun.feng@gmail.com \
--cc=aeh@meta.com \
--cc=dave@stgolabs.net \
--cc=edumazet@google.com \
--cc=elundgren@meta.com \
--cc=frederic@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiangshanlai@gmail.com \
--cc=joelagnelf@nvidia.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang@linux.dev \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=urezki@gmail.com \
--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.