Re: [Qemu-discuss] Puzzling performance comparison with KVM and Hyper-V

[Tim Bell]

> -----Original Message-----
> From: Stephan von Krawczynski [mailto:address@hidden
> Sent: 21 July 2015 18:05
> To: Carlos Torres <address@hidden>
> Cc: Tim Bell <address@hidden>; address@hidden
> Subject: Re: [Qemu-discuss] Puzzling performance comparison with KVM
> and Hyper-V
> 
> On Tue, 21 Jul 2015 15:12:26 +0000
> Carlos Torres <address@hidden> wrote:
> 
> >
> > ________________________________________
> > From: Tim Bell <address@hidden>
> > Sent: Tuesday, July 21, 2015 9:53 AM
> > To: Stephan von Krawczynski
> > Cc: Carlos Torres; address@hidden
> > Subject: Re: [Qemu-discuss] Puzzling performance comparison with KVM
> > and Hyper-V
> >
> > On Tue, 21 Jul 2015, Stephan von Krawczynski wrote:
> >
> > > On Tue, 21 Jul 2015 16:16:22 +0200
> > > Tim Bell <address@hidden> wrote:
> > >
> > >>
> > >>
> > >> On Tue, 21 Jul 2015, Carlos Torres wrote:
> > >>
> > >>> On Jul 21, 2015 5:45 AM, Tim Bell <address@hidden> wrote:
> >
> > >
> > > Have you worked out the pinning? The cpu numbers are _not_ in line
> > > with core/SMT distribution over the physical dies.
> > >
> >
> > I think we did it correctly but please give me some pointers to check...
> > the vCPU to CPU mapping we used was as below
> >
> > vCPU:CPU
> > 0: 0
> > 1: 1
> > 2: 2
> > 3: 3
> > 4: 4
> > 5: 5
> > 6: 6
> > 7: 7
> > 8: 16
> > 9: 17
> > 10: 18
> > 11: 19
> > 12: 20
> > 13: 21
> > 14: 22
> > 15: 23
> > 16: 8
> > 17: 9
> > 18: 10
> > 19: 11
> > 20: 12
> > 21: 13
> > 22: 14
> > 23: 15
> > 24: 24
> > 25: 25
> > 26: 26
> > 27: 27
> > 28: 28
> > 29: 29
> > 30: 30
> > 31: 31
> >
> > >
> > > --
> > > Regards,
> > > Stephan
> > >
> >
> > Hi Tim,
> >
> > 'cat /proc/cpuinfo' should give you this information, look at the
> > processor, physical id and core id values
> >
> > For example, here's an excerpt from my laptop that has 4 physical cores
> up to 2 threads per core (8 cpus total).
> >
> > processor       : 0                         <=== CPU # given by the OS
> > vendor_id       : GenuineIntel
> > .....
> > physical id     : 0                         <==== Physical Processor Socket 
> > ID
> > siblings        : 8
> > core id         : 0                           <==== Physical CPU Core ID
> > cpu cores       : 4
> > ....
> >
> > processor       : 1
> > vendor_id       : GenuineIntel
> > .....
> > physical id     : 0                        <=== Same Processor socket (my 
> > laptop has
> only 1)
> > siblings        : 8
> > core id         : 1                          <==== Distinct CPU Physical 
> > core
> > cpu cores       : 4
> >
> > ....
> >
> > processor       : 4
> > vendor_id       : GenuineIntel
> > .....
> > physical id     : 0                      <=== Still same Processor socket 
> > (expected)
> > siblings        : 8
> > core id         : 0                        <=== Note this is the same 
> > physical core as
> processor 0 above
> > cpu cores       : 4
> >
> >
> > -- Carlos Torres
> 
> Carlos is right. You have to closely check /proc/cpuinfo, look at this example
> from a box with 2 physical processors and 8 cores 2 threads each (32
> overall):
> 
> processor       : 0
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> 
> processor       : 1
> physical id     : 1
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> 
> processor       : 2
> physical id     : 0
> siblings        : 16
> core id         : 1
> cpu cores       : 8
> 
> processor       : 3
> physical id     : 1
> siblings        : 16
> core id         : 1
> cpu cores       : 8
> 
> ...
> 
> As you can see processor 0 and 2 are on physical id 0 but processor 1 and 3
> are on physical id _1_. This means that 0 and 1 are on a completely
> different die inside the box which has heavy impact on numa setup and
> access.
> There is no hint anyone can give you, you have to check your very personal
> setup here to find out what logical processor is located where.
> You have to arrange the pinning so that multiple processors in one virtual
> host are located as near as possible. Stay on the same die and if possible
> use the SMT as nearest neighbor because it has the same cache.
> 

Thanks. We'll try a mini cloud  up with OpenStack Kilo since there are lots of 
Numa and THP changes there. We can then see what else needs further tuning. 

> --
> Regards,
> Stephan