On Wed, Sep 04, 2024 at 10:43:23PM +0200, David Hildenbrand wrote:
> On 04.09.24 21:16, Peter Xu wrote:
> > Zhiyi reported an infinite loop issue in VFIO use case. The cause of that
> > was a separate discussion, however during that I found a regression of
> > dirty sync slowness when profiling.
> >
> > Each KVMMemoryListerner maintains an array of kvm memslots. Currently it's
> > statically allocated to be the max supported by the kernel. However after
> > Linux commit 4fc096a99e ("KVM: Raise the maximum number of user memslots"),
> > the max supported memslots reported now grows to some number large enough
> > so that it may not be wise to always statically allocate with the max
> > reported.
> >
> > What's worse, QEMU kvm code still walks all the allocated memslots entries
> > to do any form of lookups. It can drastically slow down all memslot
> > operations because each of such loop can run over 32K times on the new
> > kernels.
> >
> > Fix this issue by making the memslots to be allocated dynamically.
>
> Wouldn't it be sufficient to limit the walk to the actually used slots?
>
> I know, the large allocation might sound scary at first, but memory
> overcommit+populate-on-demand should handle that, assuming nobody touches
> the yet-unused slots.
I thought we can have holes within the array?
I meant e.g. when 10 slots populated, but then one of them got removed,
then nr_slots_used would be 9 even if slots[9] is still in use?
Thanks,
--
Peter Xu
