[Top][All Lists]

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

Re: [Qemu-ppc] TCG PPC performance regression?

From: Jan Kiszka
Subject: Re: [Qemu-ppc] TCG PPC performance regression?
Date: Tue, 06 Mar 2012 10:58:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2012-03-06 10:34, Mark Cave-Ayland wrote:
> 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.

Would I could imagine spontaneously is that my patch changed some memory
allocation ordering and, thus, maybe some alignment. But this is just a
blind guess.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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