On Sat, Sep 19, 2026 at 10:00:06AM -0700, Linus Torvalds wrote:
> On Sat, 19 Sept 2026 at 09:35, Bradley Morgan <[email protected]> wrote:
> >
> > I think hazard pointers are good, what test do YOU suggest we do here?
>
> I want to see a single real-world example of "look, this speeds this
> real load up by 10%, and the kernel code was actually cleaned up in
> the process because hazard pointers are great".
>
> Not a microbenchmark that tests just the hazard pointers themselves,
> but a real kernel feature that has been converted to hazard pointers,
> and in the process actually shows improvement.
>
> The ONLY reason for hazard pointers to ever be merged is if they
> actually buy us something real.
>
> So I want to see that 'real" thing.
>
> I want to see how easy/hard it is to actually convert a real current
> user, and I want to see how it actually results in measurable
> improvements in performance.
>
> Something *core*. Something that everybody uses. Because I'm not in
> the least interested in a new subtle feature that interacts with the
> scheduler and is only used for some random driver or (to pick the only
> example I have ever seen) AppArmor.
Just a historical note for those who were not around at the time.
Linus had a similar healthy skepticism of RCU back in the day, and
we (well, mostly Dipankar Sarma) did deliver the required use cases
and performance results. It took about two years, with the earliest
discussions at OLS 2000.
And I won't be sending a hazard-pointer pull request to Linus unless and
until we have something convincing. And if I turn out to be easier to
convince than Linus is, I am sure that he will let me know. ;-)
> Now, obviously, the thing that would impress me is something like the
> dcache. If *that* can be converted, and it shows real improvements on
> some real benchmark, then I'm sold.
And yes, the reason that I am pushing this is that some corner cases are
stressing RCU a bit, and perhaps hazard pointers can do a better job of
addressing these situations. And maybe dcache is one of those corner
cases, but it would not be first on my list, in part because hazard
pointers tends to have a bit higher read-side overhead than does RCU.
And I don't see a way that hazard pointers could eliminate dcache's use
of seqlock.
The most obvious potential hazard-pointers use case is where someone
wanted to use per-CPU reference counts, but couldn't due to the high
memory footprint of all those per-CPU counters. With a key word being
"potential" because I don't know of such a use case.
But if one shows up on an emergency basis, I want at least a prototype
of a ready solution. After all, the Linux kernel is a *lot* less
bug-tolerant than it was in the early RCU days.
> Now, I don't really expect that kind of major test-case, but I do
> expect *something* meaningful. Not a driver. Not a test module. Real
> code.
>
> IOW: "Show me the money".
>
> Because the kernel is *not* some kind of acadmic project. Never has been.
>
> I simply don't want to merge something that is touted as an
> alterantive to RCU - which we obviously depend on very very heavily -
> without something *major* that actually uses it and shows the
> real-world advantages.
>
> The discussion about hazard pointers in the kernel has been around for
> a few years by now. If there isn't some real core feature that was
> converted to show that, then I think that's already a failure
> indication.
That is of course completely fair.
And there are a couple of potential hazard-pointers use cases that have a
reasonable chance of working out. If something compelling does show up,
you will of course see a pull request. If not, maybe I maintain hazard
pointers out of tree for a few more years and then drop it. (At which
point, Murphy being who he is, a use case would promptly appear.)
> I'm hoping that those patches and numbers already exist, and I just
> haven't seen them.
There are some, but not yet compelling. This is still a work in progress.
So why bother you with premature hazard-pointer patches?
Because if a hazard-pointers-shaped problem does show up in the kernel
somewhere outside of my admittedly narrow field of view, it would be
good if you were aware.
Thanx, Paul
