[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: |
Thu, 25 Mar 2010 12:33:33 -0500 |
User-agent: |
KMail/1.11.2 (Linux/2.6.28-18-generic; KDE/4.2.2; x86_64; ; ) |
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
- [Qemu-devel] Significant performance regression in qemu-system-mips., Rob Landley, 2010/03/24
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Artyom Tarasenko, 2010/03/25
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips.,
Rob Landley <=
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Rob Landley, 2010/03/26
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Aurelien Jarno, 2010/03/26
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Rob Landley, 2010/03/26
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Aurelien Jarno, 2010/03/27
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Rob Landley, 2010/03/27
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Aurelien Jarno, 2010/03/28
- Re: [Qemu-devel] Significant performance regression in qemu-system-mips., Rob Landley, 2010/03/28