From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R77hJ-0008UH-IJ for qemu-devel@nongnu.org; Fri, 23 Sep 2011 11:29:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R77hI-0004bj-B7 for qemu-devel@nongnu.org; Fri, 23 Sep 2011 11:29:53 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:50851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R77hH-0004a3-Rl for qemu-devel@nongnu.org; Fri, 23 Sep 2011 11:29:52 -0400 Message-ID: <4E7CA5E8.7030304@rdsoftware.de> Date: Fri, 23 Sep 2011 17:29:44 +0200 From: Erik Rull MIME-Version: 1.0 References: <0NZZCL-1R6MRY0ITD-0002EJ@icpu820.kundenserver.de> <1316635372.4443.104.camel@bling.home> <4E7B6598.307@rdsoftware.de> <1316711751.25092.6.camel@x201.home> In-Reply-To: <1316711751.25092.6.camel@x201.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Enabling Hyperthreading for Guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel@nongnu.org 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. Best regards, Erik