[Qemu-ppc] TCG PPC performance regression?

[Mark Cave-Ayland]

Hi all,

Now that PPC VGA is fixed, I've been testing some patches to see if I 
can get HelenOS to boot again and was quite surprised to find that they 
seemed to be introducing a high performance overhead. However, what 
surprised me even more was that I was able to reproduce this without any 
of my custom patches applied.

So here are the basics for my Debian Squeeze development laptop:

address@hidden:~/src/qemu/git/qemu$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.4 --enable-shared --enable-multiarch 
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib 
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc --with-arch-32=i586 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)

address@hidden:~/src/qemu/git/qemu$ uname -a
Linux kentang 2.6.39-bpo.2-amd64 #1 SMP Tue Jul 26 10:35:23 UTC 2011 
x86_64 GNU/Linux

My test case is extremely simple: I'm trying to do some work on OpenBIOS 
and so I'm simply booting my primary FC12 test image 
(http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/12/Fedora/ppc/iso/Fedora-12-ppc-netinst.iso) 
to ensure that I haven't managed to break anything. All I'm doing at the 
moment is firing up my test CD image in QEMU and then timing from 
hitting enter at the yaboot prompt through to displaying the Fedora "Out 
of memory" warning on screen (since 128MB apparently isn't enough to 
install).

According to git bisect, the performance regression was introduced by 
the following commit:

commit d5ab9713d2d4037fd56b0adddd26c8d4dc11cf09
Author: Jan Kiszka <address@hidden>
Date:   Tue Aug 2 16:10:21 2011 +0200

    Avoid allocating TCG resources in non-TCG mode

    Do not allocate TCG-only resources like the translation buffer when
    running over KVM or XEN. Saves a "few" bytes in the qemu address space
    and is also conceptually cleaner.

    Signed-off-by: Jan Kiszka <address@hidden>
    Signed-off-by: Anthony Liguori <address@hidden>

And indeed, checking out both the above revision and the revision before 
it shows some startling timing differences in my simple test above:

8417cebfda193c7f9ca70be5e308eaa92cf84b94: ~10s
d5ab9713d2d4037fd56b0adddd26c8d4dc11cf09: ~20s

So according to the timings, the above patch has effectively halved the 
performance of TCG! I've rebuilt each of the above revisions several 
times and I can reproduce the problem 100% of the time here. My command 
line to launch QEMU is simply:

./qemu-system-ppc -cdrom Fedora-12-ppc-netinst.iso -boot d

Interestingly I've performed the same timing test on git master and get 
the following:

da71ebd1450fcf6f0c424810a37ec6abee02a22b: ~17s

This indicates that there has been some improvement in performance 
compared to the ~20s of the original commit, but it still seems much 
slower than the ~10s before this patch was applied.

Since I can reproduce this problem 100% of the time, I'm now trying to 
verify whether or not this is an actual bug with just my setup, or a bug 
in QEMU. I've had a look at the Jan's patch and can't see anything 
immediately obvious that would cause this, so I'm wondering if this is 
perhaps somehow compiler related? Any hints or reproduction of results 
would be greatly appreciated.


Many thanks,

Mark.