On Sun, Sep 27, 2026 at 01:15:39PM -0400, Mathieu Desnoyers wrote:
> On 2026-09-27 12:40, Boqun Feng wrote:
> > On Sun, Sep 27, 2026 at 11:51:31AM -0400, Mathieu Desnoyers wrote:
> > > Introduce a "try acquire" hazard pointer fast path, which performs an
> > > early load of the address to store it into the hazard pointer slot, and
> > > then re-loads that address after a barrier to check whether it has
> > > changed meanwhile.
> > >
> > > On comparison failure, rather than re-try, guarantee forward progress by
> > > falling back to the __hazptr_acquire slow path on failure.
> > >
> > > The acquire slow path attempts a try-acquire for any available per-CPU
> > > slot. If that fails, it chains the backup slot into the overflow list,
> > > therefore guaranteeing forward progress for both hazard pointer
> > > read-side and synchronize:
> > >
> > > - Readers set the wildcard, and then proceed to set the more
> > > specific address to replace the wildcard.
> > >
> > > - One synchronize alternates between two overflow list periods,
> > > scanning each one while readers are added to the other period,
> > > thus preventing a steady flow of readers from preventing
> > > synchronize forward progress.
> > >
> > > With this change, the scan on per-CPU slots don't need to expect a
> > > wildcard anymore, because none can be produced by readers. Wildcards are
> > > only expected within overflow lists.
> > >
> >
> > Ok, I was missing something, but I think it's better to call it out.
> > Wildcards can only exist in the overflow lists when the context is not
> > preemptible. In other words, there won't be a preempted readers blocking
> > the synchronize_hazptr() with a wilcard in the overflow list.
>
> Exactly ! Wildcard slots only exist during the short time-frame of the
> preempt-off read-side code region (few instructions). And with this
> patch, this does not even happen very often, because the fast path don't
> rely on the wildcards.
One advantage of getting rid of the wildcards completely is that it
brings out hazard-pointers resistance to blocking. Even vCPU preemption
would not do more than block reclamation of the nodes referenced by the
preempted vCPU's current hazard pointers.
Thanx, Paul