Re: [PATCH 00/17] KVM: Use atomic SRCU for gfn-to-pfn cache, reinstate guest mode for x86 nesting

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Tue, 2026-09-22 at 11:16 +0800, KunWu Chan wrote:
> Do you happen to have any numbers comparing the GPC invalidation
> latency with regular SRCU vs. `synchronize_srcu_atomic()`? If there
> are also numbers with the reader-free fastpath, that would be useful
> for understanding its impact as well.

Yeah, I built some latency tests and was posting results in the earlier
thread¹, on a few different test hosts.

I compared against the existing rwlock, as well as SRCU both with and
without the try_synchronize_srcu() fast path. Mostly looking at the
invalidation latency, since that was Sean's stated concern with the
original RCU-based proof of concept.

All from the same test: 12 concurrent guest-memory invalidation
reproducers hammering the Xen shinfo/vcpu_info caches, 300 second
windows, measuring the invalidation drain end-to-end.

192-way Granite Rapids, PREEMPT_RT production config:

  rwlock (before this series)              avg  4.4µs   max 3.85ms
  synchronize_srcu_expedited() drain       avg  8.6µs   max 810µs
  synchronize_srcu_atomic() + fastpath     avg  ~3µs    max 801µs

The A/B numbers I have for the reader-free fast path were on different
hardware (128-way Ice Lake, production-like config):

  synchronize_srcu_atomic(), no fastpath   avg 8.0µs   max 6.0ms
  with the inline no-readers proof         avg 3.6µs   max 326µs

If you want, it isn't much effort for me to tell my friend to redo any
of the measurements.

¹ https://lore.kernel.org/all/0d4af6318ac67486858be1df8d436147b444a2d2.camel@infradead.org/

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