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

["Woodhouse, David" <dwmw@amazon.co.uk>]

[-- Attachment #1.1: Type: text/plain, Size: 1709 bytes --]

On Thu, 2026-08-06 at 09:53 -0700, Sean Christopherson wrote:
> On Wed, Aug 05, 2026, sashiko-bot@kernel.org 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...

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4017 bytes --]

[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]




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.



[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]