Re: [PATCH RFC 0/4] KVM: x86: Drastically raise KVM_USER_MEM_SLOTS limit

[Vitaly Kuznetsov <vkuznets@redhat.com>]

"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com> writes:

> Hi Vitaly,
>
> On 27.01.2021 18:55, Vitaly Kuznetsov wrote:
>> "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com> writes:
>> 
>>> On 15.01.2021 14:18, Vitaly Kuznetsov wrote:
>>>> TL;DR: any particular reason why KVM_USER_MEM_SLOTS is so low?
>>>>
>>>> Longer version:
>>>>
>>>> Current KVM_USER_MEM_SLOTS limit (509) can be a limiting factor for some
>>>> configurations. In particular, when QEMU tries to start a Windows guest
>>>> with Hyper-V SynIC enabled and e.g. 256 vCPUs the limit is hit as SynIC
>>>> requires two pages per vCPU and the guest is free to pick any GFN for
>>>> each of them, this fragments memslots as QEMU wants to have a separate
>>>> memslot for each of these pages (which are supposed to act as 'overlay'
>>>> pages).
>>>>
>>>> Memory slots are allocated dynamically in KVM when added so the only real
>>>> limitation is 'id_to_index' array which is 'short'. We don't have any
>>>> KVM_MEM_SLOTS_NUM/KVM_USER_MEM_SLOTS-sized statically defined arrays.
>>>>
>>>> We could've just raised the limit to e.g. '1021' (we have 3 private
>>>> memslots on x86) and this should be enough for now as KVM_MAX_VCPUS is
>>>> '288' but AFAIK there are plans to raise this limit as well.
>>>>
>>>
>>> I have a patch series that reworks the whole memslot thing, bringing
>>> performance improvements across the board.
>>> Will post it in few days, together with a new mini benchmark set.
>> 
>> I'm about to send a successor of this series. It will be implmenting
>> Sean's idea to make the maximum number of memslots a per-VM thing (and
>> also raise the default). Hope it won't interfere with your work!
>
> Thanks for your series and CC'ing me on it.
>
> It looks like there should be no design conflicts, I will merely need to
> rebase on top of it.
>
> By the way I had to change a bit the KVM selftest framework memslot
> handling for my stuff, too, since otherwise just adding 32k memslots
> for a test would take almost forever.
>

Yea, that's why PATCH5 of the new series increases the default timeout
from 45 seconds to 120.

-- 
Vitaly