Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation

[Sean Christopherson]

On Wed, Aug 12, 2026, David Woodhouse wrote:
> On Wed, 2026-08-12 at 16:03 +0100, David Woodhouse wrote:
> > On Wed, 2026-08-12 at 15:34 +0100, David Woodhouse wrote:
> > > On Wed, 2026-08-12 at 15:05 +0100, David Woodhouse wrote:
> > > > I'll rephrase that for my own understanding:
> > > > 
> > > > *If* we go all the way to building a whole SRCU flavour for this *and*
> > > > implementing a spin-only variant of srcu_synchronize() which is
> > > > tailored to the atomic-reader use case, *then* we don't need to remove
> > > > the non_block_{start,end} guards around the MMU notifiers, which are
> > > > basically never being called anyway and don't actually seem to protect
> > > > against any real bugs.
> > > > 
> > > > Yes?
> > > 
> > > FWIW it looks something like this. I'll throw it into my torture and
> > > latency tests, and we can see what Paul thinks of it. I'm still utterly
> > > unconvinced it's needed, but I concede it has its good points.
> > 
> > This slightly refactored version is the one that's actually going into
> > my torture tests...
> 
> Well, it survived first contact, and it's doing the soak testing now.
> 
> The average is basically no better than the try_synchronize_srcu()
> case, unsurprisingly — as *both* of them just observe that there are no
> readers and proceed immediately, in at least 99% of cases.
> 
> Like the existing rwlock case, it still manages double-digit p100
> latency even when though *doesn't* actually sleep.
> 
> I don't *hate* it, but I do question the benefit of it over try-first.

FWIW, the max latency and >8ms numbers are very appealing to me, as my concerns
with using SRCU are all about the tail latencies.

But I'm obviously not the one who'd be saddled with maintaining the code, so I'm
more than a little biased towards choosing the more complex version.

> Again, I'll defer to Paul, but personally I'd want to see a more
> compelling use case for it.
> 
>   ┌───────────────┬─────────────────────┬───────────────────┬─────────────────────┐
>   │               │      expedited      │     try-first     │       atomic        │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ median drain  │ 32-128µs            │ 4-16µs            │ 4-16µs              │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ avg           │ 118µs               │ 13.8µs            │ 12.3µs              │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ >1ms          │ ~950ppm             │ ~990ppm           │ 838ppm              │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ >8ms          │ 42ppm               │ 4.4ppm            │ 0.10ppm             │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ max           │ 33.6ms              │ 17.6ms            │ 10.25ms             │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ fallback rate │ —                   │ 1.2%              │ 0%                  │
>   ├───────────────┼─────────────────────┼───────────────────┼─────────────────────┤
>   │ sample        │ 32.6M drains, 10min │ 41M drains, 10min │ 40.5M drains, 10min │
>   └───────────────┴─────────────────────┴───────────────────┴─────────────────────┘