On Mon, Sep 16, 2013 at 11:47:10AM +0300, Gleb Natapov wrote: > On Mon, Sep 16, 2013 at 10:28:20AM +0200, Andrew Jones wrote: > > On Sun, Sep 15, 2013 at 12:08:38PM +0300, Gleb Natapov wrote: > > > On Sat, Sep 14, 2013 at 02:18:49PM +0200, Andrew Jones wrote: > > > > Take CONFIG_KVM_MAX_VCPUS from arm32, but set the default to 255. > > > > > > > > Signed-off-by: Andrew Jones <drjones@xxxxxxxxxx> > > > > --- > > > > arch/x86/include/asm/kvm_host.h | 5 +++-- > > > > arch/x86/kvm/Kconfig | 10 ++++++++++ > > > > 2 files changed, 13 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > > > > index c76ff74a98f2e..e7e9b523a8f7e 100644 > > > > --- a/arch/x86/include/asm/kvm_host.h > > > > +++ b/arch/x86/include/asm/kvm_host.h > > > > @@ -31,8 +31,9 @@ > > > > #include <asm/msr-index.h> > > > > #include <asm/asm.h> > > > > > > > > -#define KVM_MAX_VCPUS 255 > > > > -#define KVM_SOFT_MAX_VCPUS 160 > > > > +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS > > > > +#define KVM_SOFT_MAX_VCPUS min(160, KVM_MAX_VCPUS) > > > > + > > > > #define KVM_USER_MEM_SLOTS 125 > > > > /* memory slots that are not exposed to userspace */ > > > > #define KVM_PRIVATE_MEM_SLOTS 3 > > > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > > > > index a47a3e54b964b..e9532c33527ee 100644 > > > > --- a/arch/x86/kvm/Kconfig > > > > +++ b/arch/x86/kvm/Kconfig > > > > @@ -52,6 +52,16 @@ config KVM > > > > > > > > If unsure, say N. > > > > > > > > +config KVM_MAX_VCPUS > > > > + int "Number maximum supported virtual CPUs per VM" > > > > + depends on KVM > > > > + default 255 > > > > + help > > > > + Static number of max supported virtual CPUs per VM. > > > > + > > > > + Set to a lower number to save some resources. Set to a higher > > > > + number to test scalability. > > > > + > > > Maximum this can save is around 2K per VM. This is pretty insignificant > > > considering overall memory footprint even smallest VM has. > > > > Should I reword this, dropping all 'save resources' verbiage, in order to > > avoid sending a message that this option can affect resource consumption? > > Or just leave it as it is, because even though it's insignificant, it's > > still true and balances out the 'Set to a higher' part. > > > I do not think config option is necessary. The overhead is so > insignificant that there is no point in additional user visible knob, > at least while only 255 vcpu are supported. Is there a reason for anyone > to configure less them 255 vcpus here? OTOH what prevents someone from > configuring more then 255 vcpus? The reason to configure less is to be able to compile a hard limit, without having to muck with the source. E.g. if you really don't want to allow more than KVM_SOFT_MAX_VCPUS to be configured, then you can compile with CONFIG_KVM_MAX_VCPUS == KVM_SOFT_MAX_VCPUS. Nothing prevents someone from configuring more than the max in userspace, but if they try to create/use more than the max (kvm_vm_ioctl_create_vcpu), it'll fail (EINVAL). I see this as a step towards getting rid of KVM_SOFT_MAX_VCPUS. I.e. compile with whatever maximum limit you want (can support), and return online/possible cpus for the recommended number. Only configure the kernel with more than your typical maximum (was KVM_SOFT_MAX_VCPUS) for development/testing purposes. drew -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
