On Thu, Sep 24, 2026 at 12:46 AM David Woodhouse <[email protected]> wrote: > > On 23 September 2026 18:26:32 CEST, KunWu Chan <[email protected]> wrote: > >On Thu, Sep 24, 2026 at 12:07 AM David Woodhouse <[email protected]> wrote: > >> > >> On Wed, 2026-09-23 at 23:58 +0800, KunWu Chan wrote: > >> > > >> > 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. > >> > >> Most of the KVM gfn-to-pfn-cache usage is per-vCPU so doesn't get much > >> parallelism. The main case is interrupt delivery to Xen guests' event > >> channels, and I did some benchmarking of parallel interrupt delivery. > >> I'll see if I still have those results, or tell my friend to go and > >> repeat some meaningful tests. > > > >Thanks David, that would be very helpful. > > > >The parallel interrupt delivery case sounds particularly interesting. > >Please don't go to any trouble if the old results are not available. > >I really appreciate you checking, and I also appreciate your friend's > >help with the measurements. > > It's no trouble; my friend is remarkably compliant once I've held its > methodology to account and probed at its conclusions. >
Haha, fair enough. Thanks again to both of you for indulging me. :-)
