From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O8St3-0003R9-AS for qemu-devel@nongnu.org; Sun, 02 May 2010 02:42:45 -0400 Received: from [140.186.70.92] (port=36018 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8St1-0003Qi-Dq for qemu-devel@nongnu.org; Sun, 02 May 2010 02:42:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O8Ssy-0001Zu-6t for qemu-devel@nongnu.org; Sun, 02 May 2010 02:42:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30224) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O8Ssx-0001Z2-Og for qemu-devel@nongnu.org; Sun, 02 May 2010 02:42:40 -0400 Message-ID: <4BDD1ED4.20403@redhat.com> Date: Sun, 02 May 2010 09:42:28 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4BD88D84.4050601@gmail.com> <4BDA87A8.3020503@redhat.com> <4BDC7E4E.30102@gmail.com> In-Reply-To: <4BDC7E4E.30102@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Regression in vga performance between 0.11.1 and 0.12.1.1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Greenblatt Cc: "qemu-devel@nongnu.org" , kvm@vger.kernel.org On 05/01/2010 10:17 PM, Adam Greenblatt wrote: > Avi, > Sure -- you can download a tarball of kvm_stat logfiles from: > Please don't top-post. > http://misc.cyclecounters.org/qemu-logs.tgz > > I ran three workloads (a short, medium, and long) against both > 0.11.1 and 0.12.3. Each workload was started with: > > time ~/qemu-0.12.3/bin/qemu-system-x86_64 -m 1536 -soundhw es1370 -smp > 4 -usb -usbdevice tablet -vga std -cpu core2duo -snapshot -name > "VKoala (r/o)",process="VKoala" -net nic,macaddr=DE:AD:BE:EF:00:08 > -net tap,vlan=0,ifname=tap6,script=no,downscript=no > /vm/ubuntu-9.10/0008.img > > (or ~/qemu-0.11.1/bin/... and the same options.) > > For the "short" workload, I just shut down the Ubuntu guest > immediately after > it finishes logging me in. > > For the "medium" workload, I open up an 80x43 terminal window in the > guest, > and execute: > > yes 1234567890123456789012345678901234567890 | head -n 10000 > > before shutting down the guest. For the "long" workload, I open up the > same terminal window and execute: > > yes 1234567890123456789012345678901234567890 | head -n 100000 > > before shutting down the guest. > > When running these workloads under 0.12.3, you can watch the screen > redraw; > it takes 1 or 2 seconds just to put up the desktop background after > the splash screen. > Top shows the `VKoala' process as pegging one or more cpus, while the > host's > X server is essentially idle (< 5% of a cpu). > > When running these workloads under 0.11.1, the screen redraw is too > fast to > notice -- it appears to just "blink" up instantly. Top shows the > `VKoala' > process as pegging one or more cpus during boot. When the terminal is > busy, > top shows `VKoala' and the host's X server both using ~60% of a cpu -- > so the > guest is probably being somewhat limited by the host's wimpy graphics. Anthony, can this be due to the SDL changes doing bitblt using X? Looks like this regresses not only for remote displays, but also for local ones. > > Hope this is the info you needed. Thanks for your help! Aloha, > Adam > > Avi Kivity wrote: >> On 04/28/2010 10:33 PM, Adam Greenblatt wrote: >>> Hi, >>> I noticed that certain guests (for example, Ubuntu 9.04, Ubuntu 9.10, >>> and the Ubuntu 10.04 release candidate) show dramatically (~100x) >>> slower >>> graphical output when running under qemu-kvm-0.12.1.1 than under >>> qemu-kvm-0.11.1. >>> Other guests, notably Windows XP and Windows Vista, run fine under both >>> version of qemu. The regression is still present in qemu-kvm-0.12.3. >> >> >> Please post kvm_stat output for the fast and slow cases (preferably >> running the same workload, perhaps a web page displaying an animation). >> > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.