| Message ID | 4EE0273D.5030509@ozlabs.org |
|---|---|
| State | New, archived |
| Headers | show |
On 08.12.2011, at 03:55, Matt Evans wrote: > PPC KVM lacks these two capabilities, and as such a userland system must assume > a max of 4 VCPUs (following api.txt). With these, a userland can determine > a more realistic limit. > > Signed-off-by: Matt Evans <matt@ozlabs.org> > --- > > Alex: For when you're back in civilisation -- the kvmtool/PPC stuff will be > limited to 4 VCPUs until the kernel returns something for these caps. > > Cheers, Matt > > arch/powerpc/kvm/powerpc.c | 15 +++++++++++++++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > index 7c7220c..3f7219d 100644 > --- a/arch/powerpc/kvm/powerpc.c > +++ b/arch/powerpc/kvm/powerpc.c > @@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) > r = 2; > break; > #endif > + case KVM_CAP_NR_VCPUS: > + /* > + * Recommending a number of CPUs is somewhat arbitrary; we return the number of present > + * CPUs for -HV (since a host will have secondary threads "offline"), and for other KVM > + * implementations just count online CPUs. > + */ > +#ifdef CONFIG_KVM_BOOK3S_64_HV > + r = num_present_cpus(); > +#else > + r = num_online_cpus(); > +#endif That will essentially restrict us to not allow overcommitting when in the scope of a single VM. Is that what we want? You could easily run a 32-way guest on a 4-way host, even with _HV. Maybe some really big number makes more sense here. Alex PS: Please always CC kvm@vger when talking about stuff that we want feedback from non-PPC folks on. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2011-12-20 at 16:17 +0100, Alexander Graf wrote: > On 08.12.2011, at 03:55, Matt Evans wrote: > > > PPC KVM lacks these two capabilities, and as such a userland system must assume > > a max of 4 VCPUs (following api.txt). With these, a userland can determine > > a more realistic limit. > > > > Signed-off-by: Matt Evans <matt@ozlabs.org> > > --- > > > > Alex: For when you're back in civilisation -- the kvmtool/PPC stuff will be > > limited to 4 VCPUs until the kernel returns something for these caps. > > > > Cheers, Matt > > > > arch/powerpc/kvm/powerpc.c | 15 +++++++++++++++ > > 1 files changed, 15 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > > index 7c7220c..3f7219d 100644 > > --- a/arch/powerpc/kvm/powerpc.c > > +++ b/arch/powerpc/kvm/powerpc.c > > @@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) > > r = 2; > > break; > > #endif > > + case KVM_CAP_NR_VCPUS: > > + /* > > + * Recommending a number of CPUs is somewhat arbitrary; we return the number of present > > + * CPUs for -HV (since a host will have secondary threads "offline"), and for other KVM > > + * implementations just count online CPUs. > > + */ > > +#ifdef CONFIG_KVM_BOOK3S_64_HV > > + r = num_present_cpus(); > > +#else > > + r = num_online_cpus(); > > +#endif > > That will essentially restrict us to not allow overcommitting when in the scope of a single VM. Is that what we want? You could easily run a 32-way guest on a 4-way host, even with _HV. > > Maybe some really big number makes more sense here. These two caps are defined pretty well on x86: KVM_CAP_MAX_VCPUS - Absolute possible number of vcpus we can squeeze in a single guest due to some technical limitation. On x86 it's limited to 254 due to not supporting IRQ remapping. KVM_CAP_NR_VCPUS - This is actually an arbitrary number which reflects the point at which adding more vcpus over this number will actually cause a performance hit.
On 20.12.2011, at 16:32, Sasha Levin wrote: > On Tue, 2011-12-20 at 16:17 +0100, Alexander Graf wrote: >> On 08.12.2011, at 03:55, Matt Evans wrote: >> >>> PPC KVM lacks these two capabilities, and as such a userland system must assume >>> a max of 4 VCPUs (following api.txt). With these, a userland can determine >>> a more realistic limit. >>> >>> Signed-off-by: Matt Evans <matt@ozlabs.org> >>> --- >>> >>> Alex: For when you're back in civilisation -- the kvmtool/PPC stuff will be >>> limited to 4 VCPUs until the kernel returns something for these caps. >>> >>> Cheers, Matt >>> >>> arch/powerpc/kvm/powerpc.c | 15 +++++++++++++++ >>> 1 files changed, 15 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c >>> index 7c7220c..3f7219d 100644 >>> --- a/arch/powerpc/kvm/powerpc.c >>> +++ b/arch/powerpc/kvm/powerpc.c >>> @@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) >>> r = 2; >>> break; >>> #endif >>> + case KVM_CAP_NR_VCPUS: >>> + /* >>> + * Recommending a number of CPUs is somewhat arbitrary; we return the number of present >>> + * CPUs for -HV (since a host will have secondary threads "offline"), and for other KVM >>> + * implementations just count online CPUs. >>> + */ >>> +#ifdef CONFIG_KVM_BOOK3S_64_HV >>> + r = num_present_cpus(); >>> +#else >>> + r = num_online_cpus(); >>> +#endif >> >> That will essentially restrict us to not allow overcommitting when in the scope of a single VM. Is that what we want? You could easily run a 32-way guest on a 4-way host, even with _HV. >> >> Maybe some really big number makes more sense here. > > These two caps are defined pretty well on x86: > > KVM_CAP_MAX_VCPUS - Absolute possible number of vcpus we can squeeze in > a single guest due to some technical limitation. On x86 it's limited to > 254 due to not supporting IRQ remapping. > > KVM_CAP_NR_VCPUS - This is actually an arbitrary number which reflects > the point at which adding more vcpus over this number will actually > cause a performance hit. Ah cool - then it's all fine and shiny. Thanks for the reminder! :) Applied the patch to kvm-ppc-next (with 80 character line limit fixed). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 7c7220c..3f7219d 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) r = 2; break; #endif + case KVM_CAP_NR_VCPUS: + /* + * Recommending a number of CPUs is somewhat arbitrary; we return the number of present + * CPUs for -HV (since a host will have secondary threads "offline"), and for other KVM + * implementations just count online CPUs. + */ +#ifdef CONFIG_KVM_BOOK3S_64_HV + r = num_present_cpus(); +#else + r = num_online_cpus(); +#endif + break; + case KVM_CAP_MAX_VCPUS: + r = KVM_MAX_VCPUS; + break; default: r = 0; break;
PPC KVM lacks these two capabilities, and as such a userland system must assume a max of 4 VCPUs (following api.txt). With these, a userland can determine a more realistic limit. Signed-off-by: Matt Evans <matt@ozlabs.org> --- Alex: For when you're back in civilisation -- the kvmtool/PPC stuff will be limited to 4 VCPUs until the kernel returns something for these caps. Cheers, Matt arch/powerpc/kvm/powerpc.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)