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