Re: [Qemu-devel] Enabling Hyperthreading for Guest

[Alex Williamson]

On Fri, 2011-09-23 at 17:29 +0200, Erik Rull wrote:
> Alex Williamson wrote:
> > On Thu, 2011-09-22 at 18:43 +0200, Erik Rull wrote:
> >> Alex Williamson wrote:
> >>> See the extended -smp options:
> >>>
> >>> -smp n[,maxcpus=cpus][,cores=cores][,threads=threads][,sockets=sockets]
> >>>                   set the number of CPUs to 'n' [default=1]
> >>>                   maxcpus= maximum number of total cpus, including
> >>>                   offline CPUs for hotplug, etc
> >>>                   cores= number of CPU cores on one socket
> >>>                   threads= number of threads on one CPU core
> >>>                   sockets= number of discrete sockets in the system
> >>>
> >>> Try something like:
> >>>
> >>> -smp 4,cores=2,threads=2,sockets=1
> >>>
> >>> Alex
> >>>
> >>
> >> Great - the correct combination made it :-)
> >>
> >> But the SMP-Performance-Benchmark is horrible :-(
> >> "Only" between 0.35 and 1.05 for the above combination.
> >
> > I'm not sure what that means...
> >
> >> I have the same architecture on the host (2 cores w/ ht enabled) so there
> >> are enough real cores available for computation.
> >>
> >> Any idea what could slow down the performance here?
> >
> > Note that threads aren't real "full" cores, so you're likely going to
> > see some scheduling mismatches between physical threads and virtual
> > threads.  One thing that often helps smp guests is to pin vCPUs to
> > pCPUs.  You can get the vCPU thread IDs from 'info cpu' in the monitor
> > and pin each to a physical CPU with taskset.  If you're using libvirt,
> > virt-manager can configure it to do this too (as well as the cpu
> > topology).
> >
> > Alex
> >
> 
> The SMP factor means how much speed improvement was gained using SMP 
> against a single core with the same algorithm. My results showed a heavy 
> performance breakdown when doing the SMP benchmark.
> Fixing the virtual cores to the physical ones worked with taskset but 
> didn't bring that real performance improvements at all :-(
> 
> Maybe the used algorithm for benchmarking is not the best one, I will try 
> others.

So effectively you're getting 1.35x to 2.05x of the uniprocessor
performance.  On it's own, without knowing how the test fairs on the
host, that doesn't mean a whole lot.  If you're expecting 4x from a
dual-core, hyperthreaded system, it's not going to happen.  I'd guess
something in the range of 2-2.5x would be typical.  Hyperthreading is
effectively a hardware managed overcommitment of the processor, trying
to virtualize that directly to a guest introduces scheduling issues
since we don't get to control the hardware thread scheduler (other than
maybe giving it hints to switch).  I expect any published SMP benchmarks
for VMs would try not to exceed 1 vCPU per core and may even disable
hyperthreading on the system.  Thanks,

Alex