* [Qemu-devel] qemu varying performance
@ 2005-01-26 2:49 Lee
2005-01-26 13:34 ` Johannes Schindelin
0 siblings, 1 reply; 8+ messages in thread
From: Lee @ 2005-01-26 2:49 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] qemu varying performance
2005-01-26 2:49 [Qemu-devel] qemu " Lee
@ 2005-01-26 13:34 ` Johannes Schindelin
2005-01-26 14:49 ` Daniel Egger
0 siblings, 1 reply; 8+ messages in thread
From: Johannes Schindelin @ 2005-01-26 13:34 UTC (permalink / raw)
To: linuxtwidler, qemu-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] qemu varying performance
2005-01-26 13:34 ` Johannes Schindelin
@ 2005-01-26 14:49 ` Daniel Egger
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Egger @ 2005-01-26 14:49 UTC (permalink / raw)
To: qemu-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] Qemu varying performance
@ 2011-09-28 0:25 Torbjorn Granlund
2011-09-28 7:15 ` Andreas Färber
2011-09-28 9:34 ` Edgar E. Iglesias
0 siblings, 2 replies; 8+ messages in thread
From: Torbjorn Granlund @ 2011-09-28 0:25 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Qemu varying performance
2011-09-28 0:25 [Qemu-devel] Qemu varying performance Torbjorn Granlund
@ 2011-09-28 7:15 ` Andreas Färber
2011-09-28 8:23 ` Torbjorn Granlund
2011-09-28 9:34 ` Edgar E. Iglesias
1 sibling, 1 reply; 8+ messages in thread
From: Andreas Färber @ 2011-09-28 7:15 UTC (permalink / raw)
To: Torbjorn Granlund; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Qemu varying performance
2011-09-28 7:15 ` Andreas Färber
@ 2011-09-28 8:23 ` Torbjorn Granlund
0 siblings, 0 replies; 8+ messages in thread
From: Torbjorn Granlund @ 2011-09-28 8:23 UTC (permalink / raw)
To: Andreas Färber; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Qemu varying performance
2011-09-28 0:25 [Qemu-devel] Qemu varying performance Torbjorn Granlund
2011-09-28 7:15 ` Andreas Färber
@ 2011-09-28 9:34 ` Edgar E. Iglesias
2011-09-29 14:53 ` Torbjorn Granlund
1 sibling, 1 reply; 8+ messages in thread
From: Edgar E. Iglesias @ 2011-09-28 9:34 UTC (permalink / raw)
To: Torbjorn Granlund; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Qemu varying performance
2011-09-28 9:34 ` Edgar E. Iglesias
@ 2011-09-29 14:53 ` Torbjorn Granlund
0 siblings, 0 replies; 8+ messages in thread
From: Torbjorn Granlund @ 2011-09-29 14:53 UTC (permalink / raw)
To: qemu-devel
"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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-09-29 14:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-28 0:25 [Qemu-devel] Qemu varying performance Torbjorn Granlund
2011-09-28 7:15 ` Andreas Färber
2011-09-28 8:23 ` Torbjorn Granlund
2011-09-28 9:34 ` Edgar E. Iglesias
2011-09-29 14:53 ` Torbjorn Granlund
-- strict thread matches above, loose matches on Subject: below --
2005-01-26 2:49 [Qemu-devel] qemu " Lee
2005-01-26 13:34 ` Johannes Schindelin
2005-01-26 14:49 ` Daniel Egger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).