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

Vitaly Kuznetsov
2021-01-27T17:57:43Z

"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!

--
Vitaly