On Tue, Sep 22, 2026 at 3:48 PM Boqun Feng <[email protected]> wrote:
>
> On Tue, Sep 22, 2026 at 03:09:46PM +0800, Kunwu Chan wrote:
> > Hi all,
> >
>
> Hello Kunwu,
>
> > This RFC/WIP extends the current v3 hazptr implementation [1] and
> > adapts the lockdep use case from Boqun Feng's earlier hazptr series [2]
> > to the current hazptr API.
> >
> > [1]
> > https://lore.kernel.org/all/[email protected]/
> > [2]
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > The lockdep conversion replaces the expedited RCU wait in
> > lockdep_unregister_key() with hazptr_synchronize() for dynamic-key
> > lookups.
> >
> > The series also adds a shared-scan kthread for concurrent
> > hazptr_synchronize() callers, rcuscale support, and an LKMM test
> > for the acquire-before-scan ordering.
> >
>
> Thanks a lot for picking up this, much appreciated.
>
> Do you happen to play a bit with rcuscale and see any performance
> difference between hazptr_synchronize() vs synchronize_{s}rcu() on
> various configs?
>
> > I tested the lockdep path on a 96-CPU ARM64 KVM guest with Boqun's
> > original mq workload [2]. With a multiqueue virtio-net device
> > (`-device virtio-net-pci,mq=on,vectors=6`), tc mq add/del x100
> > completed in 850 ms with hazptr and 860 ms with expedited RCU.
> > The rmmod workload similarly showed no measurable difference
> > (1360 ms vs. 1380 ms over 10 runs). There were no crashes or hangs
> > in these tests.
> >
>
> You could also use /proc/interrupts to measure the IPI counts during the
> whole operation, and you should be able to see the difference there.
Hi Boqun,
Thanks for the suggestions.
I collected both the rcuscale synchronization latency and the
/proc/interrupts IPI counts from the current implementation.
On a 96-CPU ARM64 KVM guest, the rcuscale results with
nreaders=0 are:
avg p50 p90 p99
nwriters=1:
hazptr 98 us 96 us 101 us 110 us
rcu 8.4 ms 8.0 ms 8.0 ms 16.0 ms
srcu 8.0 ms 15.9 ms 16.0 ms 16.0 ms
nwriters=16:
hazptr 8.0 ms 8.0 ms 8.0 ms 8.1 ms
rcu 14.9 ms 16.0 ms 16.0 ms 24.0 ms
With a single writer, hazptr completes in ~100 us. With 16
concurrent synchronizers, the latency approaches ~8 ms, while
RCU rises from ~8 ms to ~15 ms. The shared-scan batching
appears to be effective here, while the scan-kthread polling
mechanism has a significant impact on the completion latency
once multiple waiters are present. This also motivates the
Bloom-filter redesign you suggested.
For the lockdep workload (tc qdisc mq x100):
wall-clock IPI/op
hazptr ~810 ms 5.1
exp RCU ~790 ms 12.3
The hazptr path shows substantially lower IPI activity on this
workload (~41% of expedited RCU), though the wall-clock time is
similar. The lower IPI activity does not translate into a
measurable wall-clock improvement in this workload.
I'll update the shared-scan design based on your Bloom-filter
suggestion, make the rcuscale target cover multiple objects,
and add the forced-slowpath debug option. I'll then rerun
the measurements with the updated implementation.
Thanks,
Kunwu
>
> Regards,
> Boqun
>
> > This is still RFC/WIP. I would appreciate feedback on the shared-scan
> > design and the lockdep conversion.
> >
> > Kunwu Chan (4):
> > hazptr: add shared-scan kthread
> > locking/lockdep: use hazptr to wait for dynamic key lookups
> > rcuscale: add hazptr scale type
> > Documentation/litmus-tests: add hazptr acquire-before-scan test
> >
> > .../hazptr/hazptr-acquire-before-scan.litmus | 49 ++++
> > kernel/hazptr.c | 274 ++++++++++++++++++
> > kernel/locking/lockdep.c | 30 +-
> > kernel/rcu/rcuscale.c | 65 ++++-
> > 4 files changed, 407 insertions(+), 11 deletions(-)
> > create mode 100644
> > Documentation/litmus-tests/hazptr/hazptr-acquire-before-scan.litmus
> >
> > --
> > 2.43.0
> >
