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. 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. 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
