[Qemu-devel] Qemu varying performance

[Qemu-devel] Qemu varying performance

[Torbjorn Granlund]

Running Debian's vmlinux-2.6.32-5-4kc-malta under qemu-system-mips works
very well--the system is fast, and when it is idle the qemu-system-mips
process on the host system consumes insignificant CPU.  (The same is
true for qemu-system-mipsel, using the correesponding 'el' Debian
kernel.)

But running Debian's 64-bit kernel vmlinux-2.6.32-5-5kc-malta under
qemu-system-mips64 consumes 100% on the host system, whether the guest
is idle or busy.  (And for qemu-system-mips64el, the same is true for the
corresponding 64-bit el kernel.)

This cpu usage makes it somewhat inconvenient to let the qemu processes
stay running.  Is there anything that can be done about the cpu usage?
Is it a Linux problem (say, that the 64-bit kernel fails to invoke some
clever system sleep instruction when in the idle loop), or is it a qemu
problem?

Another issue I ran into what the sh4 qemu performance.  It is much
worse than other qemu ports (except perhaps ppc64).  What is the reason
behind that?  (The idle thing works well for sh4, though.)

My host system runs FreeBSD 8.2.  The Debian installs all use 6.0.2.

-- 
Torbjörn

Re: [Qemu-devel] Qemu varying performance

[Andreas Färber]

Am 28.09.2011 02:25, schrieb Torbjorn Granlund:
> Another issue I ran into what the sh4 qemu performance.  It is much
> worse than other qemu ports (except perhaps ppc64).  What is the reason
> behind that?  (The idle thing works well for sh4, though.)
>
> My host system runs FreeBSD 8.2.  The Debian installs all use 6.0.2.
Is your host 32-bit? Which architecture?

Andreas

Re: [Qemu-devel] Qemu varying performance

[Torbjorn Granlund]

Andreas Färber <andreas.faerber@web.de> writes:

  Am 28.09.2011 02:25, schrieb Torbjorn Granlund:
  > Another issue I ran into what the sh4 qemu performance.  It is much
  > worse than other qemu ports (except perhaps ppc64).  What is the reason
  > behind that?  (The idle thing works well for sh4, though.)
  >
  > My host system runs FreeBSD 8.2.  The Debian installs all use 6.0.2.
  Is your host 32-bit? Which architecture?
  
It is an amd64 system.  The CPU is a 6-core 3.2 GHz Phenom 2.  The
system has 16 GB RAM.  It is running the 64-bit version of FreeBSD.

The simulated system has only 64 MiB of RAM, but this is not the
problem; my usage of the system requires just a few MiB.

-- 
Torbjörn

Re: [Qemu-devel] Qemu varying performance

[Edgar E. Iglesias]

On Wed, Sep 28, 2011 at 02:25:43AM +0200, Torbjorn Granlund wrote:
> Running Debian's vmlinux-2.6.32-5-4kc-malta under qemu-system-mips works
> very well--the system is fast, and when it is idle the qemu-system-mips
> process on the host system consumes insignificant CPU.  (The same is
> true for qemu-system-mipsel, using the correesponding 'el' Debian
> kernel.)
> 
> But running Debian's 64-bit kernel vmlinux-2.6.32-5-5kc-malta under
> qemu-system-mips64 consumes 100% on the host system, whether the guest
> is idle or busy.  (And for qemu-system-mips64el, the same is true for the
> corresponding 64-bit el kernel.)
> 
> This cpu usage makes it somewhat inconvenient to let the qemu processes
> stay running.  Is there anything that can be done about the cpu usage?
> Is it a Linux problem (say, that the 64-bit kernel fails to invoke some
> clever system sleep instruction when in the idle loop), or is it a qemu
> problem?

Hi, It could be any of them or both. You'll have to dig a bit deeper and
see if WAIT insns are beeing issued and if QEMU is successfully decoding
them etc.


> Another issue I ran into what the sh4 qemu performance.  It is much
> worse than other qemu ports (except perhaps ppc64).  What is the reason
> behind that?  (The idle thing works well for sh4, though.)

IIRC, the SH has an MMU that is a bit problematic wrt performance in QEMU.

Cheers

Re: [Qemu-devel] Qemu varying performance

[Torbjorn Granlund]

"Edgar E. Iglesias" <edgar.iglesias@gmail.com> writes:

  > But running Debian's 64-bit kernel vmlinux-2.6.32-5-5kc-malta under
  > qemu-system-mips64 consumes 100% on the host system, whether the guest
  > is idle or busy.  (And for qemu-system-mips64el, the same is true for the
  > corresponding 64-bit el kernel.)

  Hi, It could be any of them or both. You'll have to dig a bit deeper and
  see if WAIT insns are beeing issued and if QEMU is successfully decoding
  them etc.
  
Thanks for this advice!

I naively ran 'objdump -dw' on the kernel, looked for wait, and thanks
to the naming of kernel idle loop functions, was able to make educated
guesses about which processors would be fed the 'wait' instruction.

The feeble conclusion made, that passing '-cpu 5Kc' to
qemu-system-mips64{el,} would help, turned out to be correct--now my
mips64 systems uses insignificant host CPU when they idle.

-- 
Torbjörn

[Qemu-devel] qemu varying performance

[Lee]

Hello,

Im not sure if this is a bug, but I wanted to mention it anyways.

My host computer is running the 2.4.24 kernel with smp support, xfree86,
and openbox for the window manager (16 virtual desktops).

when i am on the desktop that qemu is running on, the performance seems
normal to me.

then i will switch to a different desktop and work there for a while
(expecting that qemu will continue processing on the other desktop).

then after a while i will go back to the qemu virtual desktop and it seems
that qemu will then pick up where it left off at (either there or a little
bit after that point) and run again at normal speed.

this seems like qemu does a MAJOR slow down when it is not being displayed
on the active desktop.

has anyone else noticed this behavior?



-- 
Lee
linuxtwidler@gmail.com

Re: [Qemu-devel] qemu varying performance

[Johannes Schindelin]

Hi,

On Tue, 25 Jan 2005, Lee wrote:

> this seems like qemu does a MAJOR slow down when it is not being displayed
> on the active desktop.

I noticed something like this, too. I think the reason lies within SDL.
Could you try the same programs, but with rfb as displaying end (just
close the viewer for a while and check if QEmu was lower, too)?

Ciao,
Dscho

Re: [Qemu-devel] qemu varying performance

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On 26.01.2005, at 14:34, Johannes Schindelin wrote:

> I noticed something like this, too. I think the reason lies within SDL.
> Could you try the same programs, but with rfb as displaying end (just
> close the viewer for a while and check if QEmu was lower, too)?

The rfb patch (version 9 that is) does not apply cleanly against
current CVS; it clashes badly with the new keyboard stuff. Also it
does not compile cleanly on Debian (sarge) because some of the
elements of IIRC the rfbServer structure have a different name.

After resolving the issues it segfaults when starting up with -vnc
because of the keyboard stuff and I comment that part out it cannot
allocate an rfbServer structure (i.e. the initialisation call
returns 0) and I haven't had the time yet to figure out why....

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]