[libvirt-users] why increasing vCPUs increasing the CPU sockets for QEMU+KVM

Daniel P. Berrange berrange at redhat.com
Tue Jun 6 09:36:59 UTC 2017


On Tue, Jun 06, 2017 at 12:57:25AM +0530, girish kumar wrote:
> Hi Daniel,
> 
> Thanks a lot for the quick and detailed explanation. Please see my another
> query below.
> 
> >>In normal usage, the guest vCPUs will be floating arbitrarily across any
> >>host physical CPUs.  So trying to match host / guest topology is not only
> >>useless, it might actually degrade your performance - eg if you give the
> >>guest 1 socket, 1 core and 2 threads, but he vCPUs get scheduled on
> different
> >>thost sockets, the guest OS will make very bad decisions.
> 
> The above is true, only if the the host have multiple sockets. As long as
> the host has single socket, there will not be any performance degradation
> right?

Even if you only have a single socket, you may still have multiple cores
and multiple threads, so it still potentially applies.

> >>If you are willing, however, to assign dedicated host CPUs to each guest
> >>CPU, then you can try to match the host + guest topology. That will
> improve
> >>performance, since the guest CPUs will be fixed to specific host CPUs.
> THis
> >>isn't suitable as a default config though, hence libvirt/QEMU's default
> >>behaviour of using sockets for all vCPUs.
> Will try the advanced configuration to match the guest to host. I am kind
> of looking for a configuration which launches qemu with "-cpu host" option.

The '-cpu host' setup is not related to sockets/cores/threads topology.
That exclusively controls CPU feature flags. This is accessible in
libvirt using

   <cpu mode="host-passthrough"/>

> 
> On 5 June 2017 at 21:10, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > On Mon, Jun 05, 2017 at 08:40:19PM +0530, girish kumar wrote:
> > > Hi All,
> > >
> > > I am new here, please warn me If I am not following proper etiquette of
> > > this mailing list.
> > >
> > > I am breaking my head, regarding why libvirt is defining multiple CPU
> > > sockets when I increase the vCPU count. As and when I increase the vCPU
> > > count in libvirt guest XML, it is increasing the CPU sockets in qemu
> > > instance.
> > >
> > > " -smp 4,sockets=4,cores=1,threads=1 " instead " -smp
> > > 4,sockets=1,cores=4,threads=1"
> > >
> > > Does not this lower the performance of the guest as the host and guest
> > > architectures gets different in that case.
> > >
> > > Also please suggest a guest configuration which will take advantage of
> > the
> > > host CPU architecture.
> >
> > In normal usage, the guest vCPUs will be floating arbitrarily across any
> > host physical CPUs.  So trying to match host / guest topology is not only
> > useless, it might actually degrade your performance - eg if you give the
> > guest 1 socket, 1 core and 2 threads, but he vCPUs get scheduled on
> > different
> > thost sockets, the guest OS will make very bad decisions.
> >
> > By defaulting to giving the guest only sockets, you get fixed predictable
> > behaviour from the guest OS, as the host OS moves vCPUs threads around.
> >
> > If you are willing, however, to assign dedicated host CPUs to each guest
> > CPU, then you can try to match the host + guest topology. That will improve
> > performance, since the guest CPUs will be fixed to specific host CPUs. THis
> > isn't suitable as a default config though, hence libvirt/QEMU's default
> > behaviour of using sockets for all vCPUs.
> >
> > Regards,
> > Daniel
> > --
> > |: https://berrange.com      -o-    https://www.flickr.com/photos/
> > dberrange :|
> > |: https://libvirt.org         -o-
> > https://fstop138.berrange.com :|
> > |: https://entangle-photo.org    -o-    https://www.instagram.com/
> > dberrange :|
> >
> 
> 
> 
> -- 
> Regards,
> Girish

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvirt-users mailing list