On Wed, Sep 23, 2026 at 8:05 PM David Woodhouse <[email protected]> wrote: > > 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.
Hi David, Thanks again to you and your friend for digging out the missing results and running the additional measurements. I really appreciate the effort. These real-workload results are very valuable for understanding how the different approaches behave in a KVM workload. The results also make the effect of the reader-free fastpath much clearer. In the measurements on both systems, it substantially reduces the average invalidation latency of synchronize_srcu_atomic() compared with the same implementation without the fastpath. You mentioned that the SRCU read side scales a lot better and avoids cacheline bouncing. If you happen to have any existing measurements of the reader side, such as throughput or reader-side latency, I would be very interested in seeing them. That would be useful for understanding the reader-side benefit you mentioned. Of course, no need to rerun anything just for this. I was mainly wondering whether you already had such data from the existing testing. Thanks again for all the help. If you notice anything else in this workload that would be interesting to look at, I'd be very happy to dig into it. Thanks, Kunwu
