From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aurelien Jarno Subject: Re: [ANNOUNCE] kvm-14 release Date: Tue, 20 Feb 2007 23:24:20 +0100 Message-ID: <45DB7514.3040409@aurel32.net> References: <45D98390.6060001@qumranet.com> <45DA25D9.1060509@aurel32.net> <45DA9FFA.2020009@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <45DA9FFA.2020009-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Avi Kivity a =E9crit : > Aurelien Jarno wrote: >> The bad news is that kvm-14 seems to be a lot slower than kvm-12 + >> modules from kernel 2.6.20. This is the case with a GNU/kFreeBSD guest. >> kvm-12 was about 1.5 time faster than qemu + kqemu. kvm-20 is slower >> than qemu without kqemu... >> >> Does anybody have an idea about this performance regression? >> = > = > What is your workload? How are you measuring performance? Sorry to answer only now, it took me some time to do some more measurements and have some numbers. I am simply building a Debian package (simulpic) and measuring the build time. Basically the command is: apt-get source simulpic cd simulpic-2005-1-28 time debuild -uc us It surely not a performance index, but I guess it is ok to compare performances between version. It is also quite representative of my use of the machine. The guest is Debian GNU/kFreeBSD amd64 (ie FreeBSD kernel + GNU libc). It is accessed via ssh, and kvm is started with -nographic, so there is no influence of xorg. I am doing my tests on an Athlon X2 3800+ machine, running a 2.6.20 kernel. During all my tests, the machine is not loaded with other tasks (except systems tasks), so qemu or kvm have a full core available. Top shows that the core is used between 95 and 100% during the whole build in all cases. The tests I have made are presented below. In all cases I have verified that the real time correspond to the time of my wall clock, it is correct in all case given the resolution of my wall clock (1 s): qemu ---- real 3m16.626s user 2m22.654s sys 0m41.738s qemu + kqemu ------------ real 0m51.529s user 0m11.775s sys 0m36.215s kvm 12 + modules from kernel 2.6.20 ----------------------------------- real 0m30.635s user 0m16.357s sys 0m8.511s kvm 12 ------ real 0m25.357s user 0m16.259s sys 0m6.496s kvm 13 ------ real 0m23.415s user 0m15.177s sys 0m5.811s kvm 14 ------ real 7m47.310s user 5m17.359s sys 2m3.184s Using kvm 14, the system is clearly not responsive at all. You can see that without running a benchmark. Also running Hurd under kvm shows the same problem, though I can't make such measurements, because it does not run under kvm < 14. Note however that the ping time of the guest machine running Hurd during I/O increases from a few milliseconds to a dozen of seconds. -- = .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org | aurelien-rXXEIb44qovR7s880joybQ@public.gmane.org `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV