Hi all,

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/20260919000056.3132131-26-paulmck@kernel.org/
[2] https://lore.kernel.org/lkml/20250625031101.12555-1-boqun.feng@gmail.com/

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.

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.

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

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/20260919000056.3132131-26-paulmck@kernel.org/
> [2] https://lore.kernel.org/lkml/20250625031101.12555-1-boqun.feng@gmail.com/
> 
> 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.

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
>

On Tue, Sep 22, 2026 at 3:48 PM Boqun Feng <boqun@kernel.org> 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/20260919000056.3132131-26-paulmck@kernel.org/
> > [2] https://lore.kernel.org/lkml/20250625031101.12555-1-boqun.feng@gmail.com/
> >
> > 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
> >