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

[Rob Landley]

On Thursday 25 March 2010 04:20:26 Artyom Tarasenko wrote:
> 2010/3/24 Rob Landley <address@hidden>:
> > I have a native build under qemu that gets killed if it doesn't produce a
> > line of output for 60 seconds (hang detection enforced by the host
> > monitoring qemu's stdout with --nographic, not from within qemu).
> >
> > In the most recent release version, it never came close to triggering on
> > mips with a 30 second timeout.  In the current -git version (well, as of
> > Thursday anyway), it triggers frequently (about 90% of the time) even
> > with a 60 second timeout.
>
> Are other platforms affected as well? Do your automated tests run
> against qemu-sparc meanwhile?

That was the only platform I hit this particular regression on.  It affects 
mips, mipsel, and mips64.

The arm, x86, and x86-64 targets built to the end just fine.

Sparc works fine from a performance perspective (the timeout doesn't trigger), 
it just dies building strace with:

  In file included from file.c:88:^M
  /usr/bin/../include/asm/stat.h:56: error: expected specifier-qualifier-list
    before 'uid16_t'^

Which is either an strace bug or something wrong with the kernel headers, 
either way I need too track that down and fix it.

Powerpc got broken by the 2.6.32->2.6.33 kernel upgrade (the hard drives don't 
work because something broke in DMA interrupt handling, I'm bisecting it), so 
I can't comment on its performance at the moment.  I'll get back to you on 
that one.

As far as I can tell the sh4 linux-kernel maintainer officially doesn't care 
about anybody who isn't employed by his company, so I'm not sure I still care 
about supporting that platform.  It's not real hardware, it's a one-company 
toy:

  http://permalink.gmane.org/gmane.linux.ports.sh.devel/7233
  http://permalink.gmane.org/gmane.linux.ports.sh.devel/7237

There aren't any system emulations for m68k and alpha upstream in qemu yet, 
although I live in hope...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds