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: 1589 bytes --]

On Wed, 2026-09-23 at 17:54 +0800, Kunwu Chan wrote:
> Thanks, this is very helpful. I've put the results together below.

That looks correct. I had my friend dig out the missing parts from runs
I haven't posted, and do the runs it hadn't run.

128-way Ice Lake, PREEMPT_DYNAMIC production-like config:

  rwlock                                   avg 0.59µs   max  330µs
  synchronize_srcu_expedited() drain       avg 3.65µs   max 4383µs
  synchronize_srcu_atomic(), no fastpath   avg 8.04µs   max 6034µs
  synchronize_srcu_atomic() + fastpath     avg 3.59µs   max  326µs

192-way Granite Rapids, PREEMPT_RT production config:

  rwlock                                   avg  4.4µs   max 3854µs
  synchronize_srcu_expedited() drain       avg  8.6µs   max  810µs
  synchronize_srcu_atomic(), no fastpath   avg 12.0µs   max  620µs
  synchronize_srcu_atomic() + fastpath     avg  ~3µs    max  801µs

The max values here are noisy and can vary by 2x per (300s) run. The
averages are fairly clean, and I think I have per-bucket breakdowns for
all of them if you really want to dig into it.

Astute readers will note that rwlock actually wins on average on the
"production-like" config, that the max is in the same ballpark as the
srcu_atomic+fastpath too, and wonder why we bothered... the point is
not just that rwlocks are the wrong thing to use for PREEMPT_RT, but
also that all we're benchmarking in the above tables is the
*invalidation* not the read side, which scales a *lot* better in the
SRCU model and doesn't bounce cache lines around.

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