From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Luvalley-2 has been released: running KVM below any operating system Date: Sun, 19 Apr 2009 15:17:32 +0300 Message-ID: <49EB165C.1040900@redhat.com> References: <3b0605b30904151853n60075dc9g51a94f94613daca@mail.gmail.com> <706158FABBBA044BAD4FE898A02E4BC232872086@pdsmsx503.ccr.corp.intel.com> <3b0605b30904170154o4e0a559do34690b877c477972@mail.gmail.com> <49EB0EA2.6090206@redhat.com> <49EB1128.9070801@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Xiaodong Yi , "Zhang, Xiantao" , "kvm@vger.kernel.org" To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39806 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756255AbZDSMRm (ORCPT ); Sun, 19 Apr 2009 08:17:42 -0400 In-Reply-To: <49EB1128.9070801@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Avi Kivity wrote: > >> Xiaodong Yi wrote: >> >>> Hi, >>> >>> I've tested the guest Linux using UnixBench 5.1.2. The platform is: >>> * Intel's Core Due CPU with 2 cores, 2GB RAM >>> * CentOS 5.2 as the dom0 Linux, i.e., the host Linux for KVM >>> * CentOS 5.2 as the guest Linux, i.e., the Linux running on the >>> virtual machine provided by Qemu >>> >>> The first set of results is for Luvalley, and the second one is for >>> KVM. As the result, Luvalley's guest Linux is 20% ~ 30% faster than >>> KVM's guest! It is very surprise to me. I had through Luvalley's guest >>> should be the same performance as KVM's. >>> >>> >>> >> Yes, it is surprising. >> >> >>> Double-Precision Whetstone 12287.7 MWIPS (10.0 s, 2 samples) >>> Double-Precision Whetstone 2166.3 MWIPS (10.2 s, 2 samples >>> >> That's by far the biggest difference. Can you confirm it isn't a typo? >> >> If not, then it looks like we have a bug in floating point handling. I >> don't think this benchmark uses sse. >> >> > > Even the native Linux numbers are not that high, rather comparable to > KVM. I suspect Luvalley is fooling the benchmark here... > Most likely timing. Likely Luvally guests time runs to slowly, so they achieve more loops per unit of guest time. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.