qemu-devel
[Top][All Lists]
Advanced

[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, 26 Mar 2010 04:53:02 -0500
User-agent: KMail/1.11.2 (Linux/2.6.28-18-generic; KDE/4.2.2; x86_64; ; )

On Thursday 25 March 2010 18:25:41 Aurelien Jarno wrote:
> On Thu, Mar 25, 2010 at 12:33:33PM -0500, Rob Landley wrote:
> > 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.
>
> This has been broken in r680 of openbios. I haven't found time to find
> the real problem though.

According to the boot messages, it looks like it moved the IRQ of the IDE 
controller from 19 to 16, thus making it shared with the serial controller.

This boots:

  ttyS0 at MMIO 0x80893020 (irq = 16) is a Z85c30 ESCC - Serial port
  ttyS1 at MMIO 0x80893000 (irq = 17) is a Z85c30 ESCC - Serial port
  ide-pmac: Found Apple Heathrow ATA controller (macio), bus ID 0, irq 19
  ide0 at 0xd1010000-0xd1010070,0xd1010160 on irq 19

This does not:

  ttyS0 at MMIO 0x80893020 (irq = 16) is a Z85c30 ESCC - Serial port
  ttyS1 at MMIO 0x80893000 (irq = 17) is a Z85c30 ESCC - Serial port
  ide-pmac: Found Apple Heathrow ATA controller (macio), bus ID 0, irq 16
  ide0 at 0xd1010000-0xd1010070,0xd1010160 on irq 16

> > 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
>
> If you continue to attack people like that, not sure I'll continue to
> care about your emails.

I'm not asking anyone to care about me personally, I'm asking them to care 
about specific technical issues.  If those issues don't interest you, they 
don't interest you.

Speaking of ppc, last month I sent this patch:

  http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00917.html

And I was under the impression people agreed with it:

  http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01044.html
  http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01714.html

But today's -git is still having that same issue, and the same patch still 
applies cleanly and fixes it for me.

> Your emails on this mailing list are always
> complaining, and it really starts to be annoying.

I tend to email when something isn't working for me, and not email when things 
are working for me, yes.

In this case, I was listing the platforms I have existing .configs to build 
system images for, and explaining why I've currently lost interest in one of 
them (sh4), despite still being interested in even older things like the alpha 
and m68k (neither of which qemu has in-tree system emulations for yet).

I was unaware of attacking anyone personally.  I've never met the sh4 
maintainer, that I'm aware of.  I disagree with his judgement call in this 
instance.  Of course I respect his right to take any position he likes, since 
he _is_ maintainer, but his position removes any motivation to put more of my 
own time into his platform just now.  (I feel similarly disinterested in 
itanium and pa-risc.)

> Aurelien

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]