Regression in vga performance between 0.11.1 and 0.12.1.1

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.
Here's the information you request when submitting a bug report:

* what cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD
Opteron 2210)

The host has two Xeon X5650 cpus.

* what kvm version you are using. If you're using git directly,
provide the output of 'git describe'.

I'm using the kvm included with the stock 2.6.32.12 kernel, and
two different
qemu-kvms: version 0.11.1, which works fine, and version
0.12.1.1, which has
the regression.

* the host kernel version

      I'm running kernel 2.6.32.12 on the host.

* what host kernel arch you are using (i386 or x86_64)

      i386.

* what guest you are using, including OS type (Linux, Windows,
Solaris, etc.), bitness (32 or 64), kernel version

Guests that are affected:
Ubuntu 9.04 - kernel 2.6.28-18, 32 bits Ubuntu 9.10 - kernel 2.6.31-20, 32 bits Ubuntu 10.04 - kernel 2.6.32-21, 32-bits
Guests that aren't affected:
Windows XP SP3, Windows Vista SP2: both 32 bits

* the qemu command line you are using to start the guest

Here's one that works:

DISPLAY=:0.2 ~/qemu0111/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/0006.img

Here's one that works, but has drastically slower graphics (the only change is which qemu-system-x86_64 I'm running.)

DISPLAY=:0.2 ~/qemu01211/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/0006.img

Here are two that work fine with either binary:

DISPLAY=:0.2 ~/qemu01211/bin/qemu-system-x86_64 -m 1536 -soundhw es1370 -usb -usbdevice tablet -localtime -vga std -cpu core2duo -snapshot -name "VXP (r/o)",process="VXP" -net nic,macaddr=DE:AD:BE:EF:00:01 -net tap,vlan=0,ifname=tap0,script=no,downscript=no /vm/xp/0024.img

DISPLAY=:0.2 ~/qemu01211/bin/qemu-system-x86_64 -m 1536 -soundhw es1370 -smp 2 -usb -usbdevice tablet -localtime -vga std -cpu core2duo -snapshot -name "VVista (r/o)",process="VVista" -net nic,macaddr=DE:AD:BE:EF:00:02 -net tap,vlan=0,ifname=tap1,script=no,downscript=no /vm/vista/0009.img

* whether the problem goes away if using the -no-kvm-irqchip or
-no-kvm-pit switch.

Neither of these switches change the results.

* whether the problem also appears with the -no-kvm switch.

This switch makes everything run so much slower that I can't tell
if it
changes the results.

Please cc me if you have any questions, as I'm not subscribed to the kvm list. Thanks for working on kvm, it's a great piece of software! Aloha,
Adam Greenblatt

Please post kvm_stat output for the fast and slow cases (preferably running the same workload, perhaps a web page displaying an animation).

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Avi,
Sure -- you can download a tarball of kvm_stat logfiles from:

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.

Hope this is the info you needed. Thanks for your help! Aloha,
Adam

Please don't top-post.

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.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.