Re: [PATCH 26/28] hazptr: Implement two-phase wildcard scan

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-09-20 10:46, Gary Guo wrote:
> On Sat Sep 19, 2026 at 1:00 AM BST, Paul E. McKenney wrote:
>> From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>>
>> Implement a two-phase wildcard scan to guarantee forward progress of
>> synchronize_hazptr() even if there is a steady stream of ill-timed
>> readers which populate wildcards into per-CPU slots.
> 
> Hmm, I am not sure that I understand the problem here. The per-CPU slot is
> scanned only once per CPU, and patch 1 already introduces flipping of the
> overflow list. What prevents the forward progress?

A steady stream of readers acquiring and releasing various hazard
pointers happening concurrently with the percpu slots checks, being
unlucky enough that each of the slot is constantly in a "wildcard"
state, thus preventing forward progress of the synchronize, just with
a steady stream of individually time-bound readers.

> 
> I think having a shared global read by all CPUs sounds really undesirable,
> especially that it gets flipped for each hazptr_synchronize -- this means that
> in the pathological case where there are a steady stream of hazptr_synchronize
> calls, each fast-path hazptr_acquire will have a cache miss reading
> hazptr_wildcard.

There is a straightforward optimization we can do if this happen to
cause performance issues: only do the flip when the synchronize
encounters a wildcard retry delay beyond a specified threshold.
So we ensure synchronize observe the absence of both wildcard
values in each cpu slots, and only flip the current wildcard on retry
delay.

This would prevent the common "frequent" synchronize case you
mention from causing cache misses on the read-side.

But I preferred to keep it simple and wait until we hit this
level of synchronize call throughput until adding that extra
complexity.

Thanks,

Mathieu

> 
> Best,
> Gary
> 
>>
>> This is performed by flipping between two wildcard values (1UL and 2UL),
>> and alternatively scanning for the opposite wildcard while newcoming
>> readers use the other one.
>>
>> There is no possibility to miss a reader because all slots for all
>> wildcards are accounted for during a synchronize.
>>
>> As a simplification, use this period flip to drive the hazptr overflow
>> list selection as well, since there is really no point is making the
>> overflow list flip use a different state.
>>
>> Protect the wildcard flip with a mutex.
>>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>> Cc: Boqun Feng <boqun@kernel.org>
>> Reviewed-by: Bradley Morgan <include@grrlz.net>
>> ---
>>   include/linux/hazptr.h |  6 ++-
>>   kernel/hazptr.c        | 98 ++++++++++++++++++++++++++++++------------
>>   2 files changed, 74 insertions(+), 30 deletions(-)
> 


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com