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

On 11 August 2026 18:26:27 BST, Jason Gunthorpe <[email protected]> wrote:
>On Tue, Aug 11, 2026 at 06:22:12PM +0100, David Woodhouse wrote:
>> On Tue, 2026-08-11 at 13:24 -0300, Jason Gunthorpe wrote:
>> > To be clear you should not be using any synchronize_[s]rcu() primitive
>> > inside the invalidation callbacks. These are well known to have
>> > multi-second delays on loaded systems which are a completely
>> > inappropriate performance characteristic for these mm callbacks.
>> > 
>> > This statement has nothing to do with deadlock.
>> > 
>> > RCU is always a trade off, you can make the read side run really fast
>> > and the write side is ghastly slow. If you can't handle the slow write
>> > you shouldn't use RCU techniques.
>> 
>> The multi-second horror stories are about the *global* RCU/SRCU
>> domains, where the grace period has to wait out arbitrary readers all
>> over the kernel.
>> 
>> This is not that. It is a dedicated srcu_struct, private to one VM,
>> and its entire reader population is a handful of KVM fast paths that
>> until now were under irqsave rwlocks.
>
>Are you sure? I've never heard that srcu has those kinds of properties.
>
>If its so fast you should just propose a non-sleeping version and
>leave the notifiers out of it
>
>Jason

I've got torture tests running for correctness on the GPC RCU conversion. I'll throw in some metrics on how often even in that pathological case we hit the wait case, and how long it actually takes.

And I can prototype the extra-expedited case that never even falls back to the WQ, but frankly I don't know if it's even worth it.