[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Significant performance regression in qemu-system-mips.
From: |
Rob Landley |
Subject: |
Re: [Qemu-devel] Significant performance regression in qemu-system-mips. |
Date: |
Fri, 2 Apr 2010 23:58:08 -0500 |
User-agent: |
KMail/1.11.2 (Linux/2.6.28-18-generic; KDE/4.2.2; x86_64; ; ) |
On Thursday 01 April 2010 16:33:09 Aurelien Jarno wrote:
> On Wed, Mar 24, 2010 at 03:34:00PM -0500, Rob Landley wrote:
> > Reverting that patch fixed it (git show HEAD | patch -R -p1), by which I
> > mean three consecutive runs with 30 second timeout didn't trigger the
> > hang detection.
>
> I have tried to reproduce the issue by measuring the boot time of a mips
> system, but it stay unchanged between before and after the patch. Do you
> have some more details about how to reproduce the issue ? Have you tried
> to pay with the -clock option?
It was fixed by commit ca5a2a4b12bd447 from Paolo Bonzini, which is in current
-git. (I just confirmed that current -git builds fine.)
If you did want to reproduce the issue get and extract
http://impactlinux.com/fwl/downloads/firmware-0.9.11.tar.bz2
Create a mips system image:
./build.sh mips
And when the noise dies down run the native build with:
sources/native-builds/static-tools.sh temp.hdc
sources/more/native-build.sh mips temp.hdc output 30
That creates a build control image (temp.hdc, with the source tarballs for
dropbear and strace and a control script to build static binaries of both),
and then runs a native build using the mips system image under qemu (it'll
grab qemu-system-mips from your $PATH), uploading the results into the
"output" directory on the host, with a 30 second inactivity timeout.
When the bug was manifesting, it usually wouldn't even complete with a 60
second timeout, let alone 30. (Paolo said disabling dynticks would help, but
his patch seems to have fixed it properly.)
Thanks,
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds