[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-ppc] TCG PPC performance regression?

From: Mark Cave-Ayland
Subject: [Qemu-ppc] TCG PPC performance regression?
Date: Tue, 06 Mar 2012 09:34:58 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120207 Icedove/3.0.11

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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]