Re: [PATCH v2] KVM: irqchip: KVM: Reduce allocation overhead in kvm_set_irq_routing()

[Sean Christopherson <seanjc@google.com>]

On Mon, May 18, 2026, Yanfei Xu wrote:
> On 2026/5/16 02:52, Sean Christopherson wrote:
> > On Fri, Dec 26, 2025, Yanfei Xu wrote:
> > And if we're going to allocate one massive array, then we definitely should get
> > rid of:
> > 
> > 	/*
> > 	 * Array indexed by gsi. Each entry contains list of irq chips
> > 	 * the gsi is connected to.
> > 	 */
> > 	struct hlist_head map[];
> > 
> > and kvm_kernel_irq_routing_entry.list.  It'd be easier and faster to have
> > setup_routing_entry() simply iterate over the array.
> 
> if we get rid of these, we need to add a new field to record the offset of
> entries belonging to the same GSI. Compared to the hlist-based lookup, I am
> not sure this would yield a clear gain. Seems hlist feels more
> straightforward?

Gah, right, I was thinking the array was indexed by GSI, but it's indexed by the
arbitrary order provided by userspace.  And even ignoring the case where a GSI
has multiple routes, indexing by GSI would massively over-allocate if the routing
table is sparsely populated.

> > Something we should look at (on top of this), is caching the previous routing
> > table.  I.e. instead of freeing the old table, keep it around, and try to reuse
> > the old table on the next update.  That would allow eliding the alloc+free
> > entirely when userspace is changing routing, but not adding or removing entries.
> 
> In our live-upgrade scenario, userspace incrementally adds entries via a
> large number of KVM_SET_GSI_ROUTING ioctls, so the cost is dominated by the
> cumulative overhead across tens of thousands of alloc/free pairs.

Yes, but your live-upgrade scenario isn't the only thing KVM supports :-)

> Per my observation, the per-call alloc/free overhead is fine; it's the
> cumulative cost that hurts.

That might change with vmalloc'd memory, where tearing down the mappings requires
TLB shutdowns.  And as above, even if it's not a problem for _your_ scenario, the
overhead might be meaningful for other setups.  If we can cheaply/easily provide
meaningful performance benefits for such setups, then why not...