Re: [Qemu-devel] Significant performance regression in qemu-system-mips.

[Rob Landley <rob@landley.net>]

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