Re: [PATCH v3 3/7] KVM: pfncache: Use RCU for readers instead of a rwlock

On Thu, 2026-08-06 at 09:53 -0700, Sean Christopherson wrote:
> On Wed, Aug 05, 2026, [email protected] wrote:
> > Replace the per-cache rwlock with RCU for the read side.
> 
> I don't hate the idea, but I am very against using RCU.  Unless it's "impossible",
> e.g. because synchronize_srcu() allocates memory and breaks OOM kill, I would
> strongly prefer to use SRCU, probably with a dedicated kvm->gpc_srcu, so that
> synchronization doesn't need to wait on all CPUs in the system.  The tail latencies
> for synchronize_rcu() are horrendous, especially for many-CPU systems.  If it
> were only mmu_notifiers that got hit, it miiiight be acceptable, but since this
> will affect vCPU tasks in the refresh() path as well, normal RCU is pretty much
> a non-starter.

Yeah, the refresh() path got pretty slow in my first attempt, before
optimising that *not* to have a grace period if the memslot generation
changed but the actual GPA→uHVA (and memslot) don't *change*.

> Even SRCU could be problematic: if synchronize_srcu_expedited() is forced to wait,
> the wait time can easily get to 20+ milliseconds, which again is a non-starter for
> things like steal-time updates and nVMX pages.

But we don't have to synchronize from the read side. The code path
which will do so most often is gfn_to_pfn_cache_invalidate_start(). And
the refresh() path which is already the fallback slow path which can
sleep. Although in my tree I've optimised that *not* to incur a grace
period when it's avoidable, as noted above.

I'm more concerned by the fact that srcu_gp_end() might have to
*allocate*, while the OOM reaper path waits for it. I'll see how we can
deal with that...




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.