On Tue, Jun 14, 2022 at 1:28 AM Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: > > David Matlack <dmatlack@xxxxxxxxxx> writes: > > > On Mon, Jun 13, 2022 at 11:35 AM Kyle Meyer <kyle.meyer@xxxxxxx> wrote: > >> > >> Increase KVM_MAX_VCPUS to 2048 so we can run larger virtual machines. > > > > Does the host machine have 2048 CPUs (or more) as well in your usecase? > > > > I'm wondering if it makes sense to start configuring KVM_MAX_VCPUS > > based on NR_CPUS. That way KVM can scale up on large machines without > > using more memory on small machines. > > > > e.g. > > > > /* Provide backwards compatibility. */ > > #if NR_CPUS < 1024 > > #define KVM_MAX_VCPUS 1024 > > #else > > #define KVM_MAX_VCPUS NR_CPUS > > #endif > > > > The only downside I can see for this approach is if you are trying to > > kick the tires a new large VM on a smaller host because the new "large > > host" hardware hasn't landed yet. Heh. My point here doesn't make sense. The actual number of CPUs in the host machine wouldn't matter, just the host kernel's NR_CPUS. > > FWIW, while I don't think there's anything wrong with such approach, it > won't help much distro kernels which are not recompiled to meet the > needs of a particular host. But is there a use-case for running a VM with more vCPUs than the kernel's NR_CPUS? > According to Kyle's numbers, the biggest > growth is observed with 'struct kvm_ioapic' and that's only because of > 'struct rtc_status' embedded in it. Maybe it's possible to use something > different from a KVM_MAX_VCPU_IDS-bound flat bitmask there? I'm not sure > how important this is as it's just another 4K per-VM and when guest's > memory is taken into account it's probably not much. > > The growth in 'struct kvm'/'struct kvm_arch' seems to be insignificant > and on-stack allocations are probably OK. > > -- > Vitaly >
