[PATCH 13/17] KVM: PPC: Allow book3s_hv guests to use SMT processor modes

Alexander Graf agraf at suse.de
Mon Apr 16 23:01:40 EST 2012


On 16.04.2012, at 14:13, Paul Mackerras wrote:

> On Mon, Apr 16, 2012 at 11:45:44AM +0200, Alexander Graf wrote:
> 
>> While trying to trace down why some BookE systems were only able to
>> do as many guest vcpus as there were host cpus available, we
>> stumbled over this one. Is there any limitation on book3s_hv that
>> would limit the available vcpus to configured host vcpus? Or could
>> we just make this a static define like on x86?
> 
> There is no limitation.  I did it like that so that we would be able
> to have a large number of vcpus on kernels configured for large
> systems, while not using up large amounts of memory if the kernel is
> configured for a small system.  The memory consumption is 8 bytes per
> vcore in each struct kvm if book3s_hv is configured.

8 * 256 = 2048. So for a limit similar to that of x86 we'd waste 2kb per VM. Doesn't sound all too horrible to me.

> We can make it a fixed constant if you like, but then the question is
> how do you choose that constant so as to allow us to have many vcpus
> on large systems but still not waste too much memory on small systems.
> Or it could be max(N, NR_CPUS) for a suitable N (e.g. 16 or 32).

Hrm. Usually we have 2 machine types:

  1) Small system with very low NR_CPUS. These systems should be able to do some overcommit at least. I'd go with a static number here, like 16 or 64.
  2) Big systems with very high NR_CPUS. Here going larger than NR_CPUS doesn't make all that much sense anymore. I'd use NR_CPUS as limit.

So how about something like

#if NR_CPUS > 64
#define KVM_MAX_VCPUS NR_CPUS
#else
#define KVM_MAX_VCPUS 64
#endif


That way everyone should be happy and we have a reasonable limit.

Alex



More information about the Linuxppc-dev mailing list