Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation
David Woodhouse <[email protected]>
| Newsgroups | dev.linux.lists.linux-rt-devel,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 2026-08-11 at 22:21 +0200, Paolo Bonzini wrote: > > for_each_present_cpu(cpu) > if (per_cpu(kvm_gpc_reader, cpu) == gpc) > cpumask_set_cpu(cpu, gpc_readers); > __kvm_kick_many_cpus(cpus, wait); I'm literally sitting here watching you reinvent what SRCU already does. Which, again, is *fine* given the behaviour of *these* read-side sections. > Alternatively, there's always the poor-man RCU using an rwlock_t; you > do read_lock/read_unlock as usual for begin/end of reads, while the > write side does > > write_lock(&kvm->gpc_readers); > write_unlock(&kvm->gpc_readers); > > in place of synchronize_src(). And now we've come full circle to the rwlock we already *have* — but which is back to a shared cache line for readers, and which RT turns into a sleeping lock, which is what I started out trying to fix in the first place. I get it. RCU is a versatile tool, and in *some* cases the *Sleepable* variant of RCU gets used in ways which would cause grace period latencies which are thoroughly unacceptable in an MMU notifier callback. But in the specific case of a dedicated kvm->gpc_srcu whose only readers are tiny snippets of code that until today were always run with rwlock_irqsave? That is *not* Jason's worst-case bugbear. It's fine.
smime.p7s
(application/pkcs7-signature, 6 KB) - not displayed