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/[email protected]/
smime.p7s
Description: S/MIME cryptographic signature
