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

[Super Bisquit]

Fedora doesn't play nice with low spec systems, which is anything with
less than 256M RAM and 32M VideoRAM. You need to try a text install
and do a basic system. Debian works for the standard qemu-system-ppc
memory settings. OpenBSD and FreeBSD should work; however, you'll need
256M RAM to compile and emulate a processor that is 400MHz or greater.

On 3/6/12, Mark Cave-Ayland <address@hidden> 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.
>
>
> Many thanks,
>
> Mark.
>
>