* [Qemu-devel] About performance of qemu-system-arm
@ 2006-12-13 8:09 PianoPan
2006-12-13 10:32 ` [Qemu-devel] " Ross Burton
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: PianoPan @ 2006-12-13 8:09 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hello, everyone,
Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before
our development, I want to confirm performance of it. I use packages from
http://folks.o-hand.com/richard/qemu.html to build the evaluation
environment, but performance of Linux in Qemu is too slow. It uses about one
hour to boot GUI system.
Can anybody tell me this performance is proper or not?
Best regards!
Piano Pan
[-- Attachment #2: Type: text/html, Size: 745 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Qemu-devel] Re: About performance of qemu-system-arm
2006-12-13 8:09 [Qemu-devel] About performance of qemu-system-arm PianoPan
@ 2006-12-13 10:32 ` Ross Burton
2006-12-13 11:22 ` [Qemu-devel] " Màrius Montón
2006-12-13 13:26 ` Martin Guy
2 siblings, 0 replies; 29+ messages in thread
From: Ross Burton @ 2006-12-13 10:32 UTC (permalink / raw)
To: qemu-devel
On Wed, 2006-12-13 at 16:09 +0800, PianoPan wrote:
> Now, I'm planning to use Qemu as our mobile device emulator (ARM).
> Before our development, I want to confirm performance of it. I use
> packages from http://folks.o-hand.com/richard/qemu.html to build the
> evaluation environment, but performance of Linux in Qemu is too slow.
> It uses about one hour to boot GUI system.
>
> Can anybody tell me this performance is proper or not?
On my laptop -- a Intel Core Duo 1.8GHz -- I can boot an OpenEmbedded
image (with X, matchbox, udev, etc) in a minute or so.
Ross
--
Ross Burton mail: ross@burtonini.com
jabber: ross@burtonini.com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] About performance of qemu-system-arm
2006-12-13 8:09 [Qemu-devel] About performance of qemu-system-arm PianoPan
2006-12-13 10:32 ` [Qemu-devel] " Ross Burton
@ 2006-12-13 11:22 ` Màrius Montón
2006-12-13 14:17 ` PianoPan
2006-12-13 13:26 ` Martin Guy
2 siblings, 1 reply; 29+ messages in thread
From: Màrius Montón @ 2006-12-13 11:22 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1.1: Type: text/plain, Size: 1297 bytes --]
Hi,
I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
It's working fine (about 1 minute to boot in my PC).
regards,
Màrius
PianoPan wrote:
> Hello, everyone,
>
>
>
> Now, I'm planning to use Qemu as our mobile device emulator (ARM).
> Before our development, I want to confirm performance of it. I use
> packages from http://folks.o-hand.com/richard/qemu.html to build the
> evaluation environment, but performance of Linux in Qemu is too slow.
> It uses about one hour to boot GUI system.
>
>
>
> Can anybody tell me this performance is proper or not?
>
> Best regards!
>
> Piano Pan
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Màrius Montón i Macián marius.monton@uab.cat
<mailto:marius.monton@uab.cat> http://cephis.uab.es
<http://www.mariusmonton.name>
Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra
[-- Attachment #1.2: Type: text/html, Size: 3072 bytes --]
[-- Attachment #2: marius.monton.vcf --]
[-- Type: text/x-vcard, Size: 440 bytes --]
begin:vcard
fn;quoted-printable:M=C3=A0rius Mont=C3=B3n
n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius
org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics
adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain
email;internet:marius.monton@uab.es
title:HW Engineer
tel;work:+34935813534
tel;fax:+34935813033
x-mozilla-html:TRUE
url:http://cephis.uab.es
version:2.1
end:vcard
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] About performance of qemu-system-arm
2006-12-13 8:09 [Qemu-devel] About performance of qemu-system-arm PianoPan
2006-12-13 10:32 ` [Qemu-devel] " Ross Burton
2006-12-13 11:22 ` [Qemu-devel] " Màrius Montón
@ 2006-12-13 13:26 ` Martin Guy
2006-12-13 14:40 ` [Qemu-devel] qemu-system-* using mmap? Tim Olson
2006-12-13 15:10 ` [Qemu-devel] About performance of qemu-system-arm Martin Guy
2 siblings, 2 replies; 29+ messages in thread
From: Martin Guy @ 2006-12-13 13:26 UTC (permalink / raw)
To: qemu-devel
2006/12/13, PianoPan <pianopan@gmail.com>:
> performance of Linux in Qemu is too slow. It
> uses about one hour to boot GUI system.
During development work this summer at one point I experienced an
immense slowdown of QEMU - from 63 bogomips to 1 or 2 on a 400MHz
Pentium. The problem went away when I upgraded the ARM linux kernel
that QEMU was running from 2.6.16 to 2.6.16-rc3 and the problem has
not come back with later versions (.17 .18)
M
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] About performance of qemu-system-arm
2006-12-13 11:22 ` [Qemu-devel] " Màrius Montón
@ 2006-12-13 14:17 ` PianoPan
2006-12-13 15:23 ` Màrius Montón
0 siblings, 1 reply; 29+ messages in thread
From: PianoPan @ 2006-12-13 14:17 UTC (permalink / raw)
To: qemu-devel
Hi Màrius:
> It's working fine (about 1 minute to boot in my PC).
Did you mean that 1 minute to boot the X system?
Regards !
Piano Pan
On 12/13/06, Màrius Montón <marius.monton@uab.es> wrote:
>
> Hi,
>
> I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
>
> It's working fine (about 1 minute to boot in my PC).
>
> regards,
>
> Màrius
>
> PianoPan wrote:
>
> Hello, everyone,
>
>
>
> Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before our development, I want to confirm performance of it. I use packages from http://folks.o-hand.com/richard/qemu.html to build the evaluation environment, but performance of Linux in Qemu is too slow. It uses about one hour to boot GUI system.
>
>
>
> Can anybody tell me this performance is proper or not?
>
> Best regards! Piano Pan
> ________________________________
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
> --
>
> Màrius Montón i Macián marius.monton@uab.cat http://cephis.uab.es
> Hardware Engineer
> CEPHIS
> Centre de Prototips i Solucions Hardware-Software
> Dep. Microelectrònica i Sistemes Electrònics
> ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534
> Fax: +34 935 813 033
> QC-2090D. ETSE. Campus UAB.
> 080193 Bellaterra
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Qemu-devel] qemu-system-* using mmap?
2006-12-13 13:26 ` Martin Guy
@ 2006-12-13 14:40 ` Tim Olson
2006-12-13 15:32 ` Paul Brook
2006-12-13 16:04 ` Joseph Miller
2006-12-13 15:10 ` [Qemu-devel] About performance of qemu-system-arm Martin Guy
1 sibling, 2 replies; 29+ messages in thread
From: Tim Olson @ 2006-12-13 14:40 UTC (permalink / raw)
To: qemu-devel
I am using qemu 0.8.2 built from source. In the qemu technical
documentation for features under full system emulation, it says:
"QEMU can either use a full software MMU for maximum portability or use
the host system call mmap() to simulate the target MMU."
However, I cannot find a way to build a full system simulator which
does not define SOFTMMU -- in fact, the configure parameters
"--disable-system" and "--enable-system" directly control the softmmu
switch. There are some mmap() calls in the kqemu code, but to use that
requires full kqemu support code in the kernel.
I think there is a big performance hit using the software mmu, as each
target load or store instruction is expanded into 20-30 host
instructions to perform the translation. Is there a way to build the
qemu-system-* emulators using the mmap() feature mentioned in the
documentation?
-- Tim Olson
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] About performance of qemu-system-arm
2006-12-13 13:26 ` Martin Guy
2006-12-13 14:40 ` [Qemu-devel] qemu-system-* using mmap? Tim Olson
@ 2006-12-13 15:10 ` Martin Guy
1 sibling, 0 replies; 29+ messages in thread
From: Martin Guy @ 2006-12-13 15:10 UTC (permalink / raw)
To: qemu-devel
2006/12/13, Martin Guy <martinwguy@yahoo.it>:
> 2006/12/13, PianoPan <pianopan@gmail.com>:
> > performance of Linux in Qemu is too slow. It
> > uses about one hour to boot GUI system.
>
> During development work this summer at one point I experienced an
> immense slowdown of QEMU - from 63 bogomips to 1 or 2
Sorry I forgot to say, that was with qemu-system-arm 0.8.2
The sort of performance you should be seeing is, for example, a 2GHz
AMD or a 4GHz Intel giving the same realtime speed as a 100-200MHz
ARM.
M
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] About performance of qemu-system-arm
2006-12-13 14:17 ` PianoPan
@ 2006-12-13 15:23 ` Màrius Montón
0 siblings, 0 replies; 29+ messages in thread
From: Màrius Montón @ 2006-12-13 15:23 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1.1: Type: text/plain, Size: 2644 bytes --]
Hi,
Sorry for my previous short answer:
It take about 1 minute to boot console login.
I don't have tested X system, but I suspect it can spent no more than 10
minutes (probably less, but I don't know)
I use "qemu-system-arm -M versatilepb ..."
Regards,
Marius
PianoPan wrote:
> Hi Màrius:
>
>> It's working fine (about 1 minute to boot in my PC).
>
> Did you mean that 1 minute to boot the X system?
>
> Regards !
>
> Piano Pan
>
> On 12/13/06, Màrius Montón <marius.monton@uab.es> wrote:
>>
>> Hi,
>>
>> I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
>>
>> It's working fine (about 1 minute to boot in my PC).
>>
>> regards,
>>
>> Màrius
>>
>> PianoPan wrote:
>>
>> Hello, everyone,
>>
>>
>>
>> Now, I'm planning to use Qemu as our mobile device emulator (ARM).
>> Before our development, I want to confirm performance of it. I use
>> packages from http://folks.o-hand.com/richard/qemu.html to build the
>> evaluation environment, but performance of Linux in Qemu is too slow.
>> It uses about one hour to boot GUI system.
>>
>>
>>
>> Can anybody tell me this performance is proper or not?
>>
>> Best regards! Piano Pan
>> ________________________________
>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>>
>> --
>>
>> Màrius Montón i Macián marius.monton@uab.cat
>> http://cephis.uab.es
>> Hardware Engineer
>> CEPHIS
>> Centre de Prototips i Solucions Hardware-Software
>> Dep. Microelectrònica i Sistemes Electrònics
>> ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34
>> 935 813 534
>> Fax: +34 935 813 033
>> QC-2090D. ETSE. Campus UAB.
>> 080193 Bellaterra
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>>
>>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Màrius Montón i Macián marius.monton@uab.cat
<mailto:marius.monton@uab.cat> http://cephis.uab.es
<http://www.mariusmonton.name>
Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra
[-- Attachment #1.2: Type: text/html, Size: 5803 bytes --]
[-- Attachment #2: marius.monton.vcf --]
[-- Type: text/x-vcard, Size: 440 bytes --]
begin:vcard
fn;quoted-printable:M=C3=A0rius Mont=C3=B3n
n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius
org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics
adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain
email;internet:marius.monton@uab.es
title:HW Engineer
tel;work:+34935813534
tel;fax:+34935813033
x-mozilla-html:TRUE
url:http://cephis.uab.es
version:2.1
end:vcard
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] qemu-system-* using mmap?
2006-12-13 14:40 ` [Qemu-devel] qemu-system-* using mmap? Tim Olson
@ 2006-12-13 15:32 ` Paul Brook
2006-12-13 16:04 ` Joseph Miller
1 sibling, 0 replies; 29+ messages in thread
From: Paul Brook @ 2006-12-13 15:32 UTC (permalink / raw)
To: qemu-devel; +Cc: Tim Olson
On Wednesday 13 December 2006 14:40, Tim Olson wrote:
> I am using qemu 0.8.2 built from source. In the qemu technical
> documentation for features under full system emulation, it says:
>
> "QEMU can either use a full software MMU for maximum portability or use
> the host system call mmap() to simulate the target MMU."
>
> However, I cannot find a way to build a full system simulator which
> does not define SOFTMMU -- in fact, the configure parameters
> "--disable-system" and "--enable-system" directly control the softmmu
> switch. There are some mmap() calls in the kqemu code, but to use that
> requires full kqemu support code in the kernel.
This is unrelated.
> I think there is a big performance hit using the software mmu, as each
> target load or store instruction is expanded into 20-30 host
> instructions to perform the translation. Is there a way to build the
> qemu-system-* emulators using the mmap() feature mentioned in the
> documentation?
No. That feature was removed some time ago. It only worked with modified guest
OS. Once you start doing that you generally may as well use UML or Xen.
It's actually more like 10 instructions to do the translation.
Paul
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] qemu-system-* using mmap?
2006-12-13 14:40 ` [Qemu-devel] qemu-system-* using mmap? Tim Olson
2006-12-13 15:32 ` Paul Brook
@ 2006-12-13 16:04 ` Joseph Miller
2006-12-14 14:50 ` Tim Olson
1 sibling, 1 reply; 29+ messages in thread
From: Joseph Miller @ 2006-12-13 16:04 UTC (permalink / raw)
To: qemu-devel
Tim Olson wrote:
> I am using qemu 0.8.2 built from source. In the qemu technical
> documentation for features under full system emulation, it says:
>
> "QEMU can either use a full software MMU for maximum portability or
> use the host system call mmap() to simulate the target MMU."
>
> However, I cannot find a way to build a full system simulator which
> does not define SOFTMMU -- in fact, the configure parameters
> "--disable-system" and "--enable-system" directly control the softmmu
> switch. There are some mmap() calls in the kqemu code, but to use
> that requires full kqemu support code in the kernel.
>
> I think there is a big performance hit using the software mmu, as each
> target load or store instruction is expanded into 20-30 host
> instructions to perform the translation. Is there a way to build the
> qemu-system-* emulators using the mmap() feature mentioned in the
> documentation?
>
> -- Tim Olson
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
Can someone elaborate on this a little? What is the difference between
the SOFTMMU and the mmap()? Should I be using the --enable-system or
the --disable-system for win32 guest on i386 debian host? Can someone
give a little more insight on this technicality?
-Joseph
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] qemu-system-* using mmap?
2006-12-13 16:04 ` Joseph Miller
@ 2006-12-14 14:50 ` Tim Olson
2006-12-14 17:01 ` [Qemu-devel] " Joseph Miller
0 siblings, 1 reply; 29+ messages in thread
From: Tim Olson @ 2006-12-14 14:50 UTC (permalink / raw)
To: qemu-devel
On Dec 13, 2006, at 10:04 AM, Joseph Miller wrote:
>
> Can someone elaborate on this a little? What is the difference
> between the SOFTMMU and the mmap()? Should I be using the
> --enable-system or the --disable-system for win32 guest on i386 debian
> host? Can someone give a little more insight on this technicality?
For full system emulation, qemu needs to support the emulated
processor's ability to perform virtual->physical address translation
for every memory reference (including data loads/stores and
non-pc-relative branches). Using the SOFTMMU method, this is done at
basic-block translation time by inlining a software TLB lookup routine
for each memory reference. This expands a simple target load
instruction into a sequence of ~20 host processor instructions (for x86
target, ppc host I see about 25 instructions for TLB lookup).
The other way to handle this would be to use the host's MMU to do the
translation directly, via an mmap() system call which sets up the
translation. Then the translated basic block would contain memory
references using the target system's virtual address values, and the
translation would occur in the host's hardware MMU during execution
(fast), rather than having to execute a software TLB lookup. However,
there are a number of restrictions to using mmap() translation (host
and target address spaces cannot overlap, etc.) It appears that this
feature has been removed from current versions of qemu, so the only way
to do full system emulation is via the SOFTMMU method.
-- tim
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] using mmap?
2006-12-14 17:01 ` [Qemu-devel] " Joseph Miller
@ 2006-12-14 16:45 ` Paul Brook
2006-12-15 16:21 ` [Qemu-devel] Qemu speed vs vmplayer? Joseph Miller
2006-12-15 16:32 ` [Qemu-devel] using mmap? Mark Williamson
0 siblings, 2 replies; 29+ messages in thread
From: Paul Brook @ 2006-12-14 16:45 UTC (permalink / raw)
To: qemu-devel
> Does anyone know the reason for the removal of the mmap()? I have used
> a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the
> memory access in the guest WinXP was slooooooow. Does anyone have any
> insight on making the hardware MMU function for linux-x86 host to WinXP
> 32-bit guest, even partially?
As I already said, the code required a modified guest OS. i.e. it wouldn't
work with windows guests anyway.
It was removed because it provided very little benefit, and wasn't worth the
effort to keep it working. Its uses were very specialised, and IMHO better
covered by other products like UML or xen.
I'm also doubtful how much benefit it gave in practice. I'm sure it would be
good for synthetic CPU benchmarks. However using mmap significantly increases
the overhead of context switches/tlb misses.
To get good overall performance I suspect you're going to need closer
cooperation with the kernel than mmap gives you. If you really want to make
cross-emulation go fast I suggest working with the xen and/or kvm people to
integrate qemu dynamic translation into those products. In theory I'd guess
you should be able to plug it in as an alternative to the HVM code. I've no
idea how close that is to being practical.
> Wouldn't this be a *significant*
> performance enhancement for this setup which I'm sure is a common one?
> Maybe this can be implemented for regular processes on the guest and
> only use the softmmu for the kernel? Would someone point me in the
> right direction for technical information? I have had to switch to
> vmware free player until Qemu+KQEMU reaches a point of similar
> performance, but I would really rather see Qemu advance further.
If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as
most code isn't run by qemu, it's virtualized by the accelerator. qemu just
does the IO emulation.
Paul
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] using mmap?
2006-12-14 14:50 ` Tim Olson
@ 2006-12-14 17:01 ` Joseph Miller
2006-12-14 16:45 ` Paul Brook
0 siblings, 1 reply; 29+ messages in thread
From: Joseph Miller @ 2006-12-14 17:01 UTC (permalink / raw)
To: qemu-devel
Tim Olson wrote:
>
> On Dec 13, 2006, at 10:04 AM, Joseph Miller wrote:
>
>>
>> Can someone elaborate on this a little? What is the difference
>> between the SOFTMMU and the mmap()? Should I be using the
>> --enable-system or the --disable-system for win32 guest on i386
>> debian host? Can someone give a little more insight on this
>> technicality?
>
> For full system emulation, qemu needs to support the emulated
> processor's ability to perform virtual->physical address translation
> for every memory reference (including data loads/stores and
> non-pc-relative branches). Using the SOFTMMU method, this is done at
> basic-block translation time by inlining a software TLB lookup routine
> for each memory reference. This expands a simple target load
> instruction into a sequence of ~20 host processor instructions (for
> x86 target, ppc host I see about 25 instructions for TLB lookup).
>
> The other way to handle this would be to use the host's MMU to do the
> translation directly, via an mmap() system call which sets up the
> translation. Then the translated basic block would contain memory
> references using the target system's virtual address values, and the
> translation would occur in the host's hardware MMU during execution
> (fast), rather than having to execute a software TLB lookup. However,
> there are a number of restrictions to using mmap() translation (host
> and target address spaces cannot overlap, etc.) It appears that this
> feature has been removed from current versions of qemu, so the only
> way to do full system emulation is via the SOFTMMU method.
>
> -- tim
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
Does anyone know the reason for the removal of the mmap()? I have used
a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the
memory access in the guest WinXP was slooooooow. Does anyone have any
insight on making the hardware MMU function for linux-x86 host to WinXP
32-bit guest, even partially? Wouldn't this be a *significant*
performance enhancement for this setup which I'm sure is a common one?
Maybe this can be implemented for regular processes on the guest and
only use the softmmu for the kernel? Would someone point me in the
right direction for technical information? I have had to switch to
vmware free player until Qemu+KQEMU reaches a point of similar
performance, but I would really rather see Qemu advance further.
-Joseph
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 16:21 ` [Qemu-devel] Qemu speed vs vmplayer? Joseph Miller
@ 2006-12-15 16:13 ` Paul Brook
2006-12-15 22:20 ` Joseph Miller
2006-12-16 5:27 ` [Qemu-devel] Qemu speed vs vmplayer? Jamie Lokier
0 siblings, 2 replies; 29+ messages in thread
From: Paul Brook @ 2006-12-15 16:13 UTC (permalink / raw)
To: qemu-devel
> > If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
> > as most code isn't run by qemu, it's virtualized by the accelerator. qemu
> > just does the IO emulation.
> >
> > Paul
>
> OK, so mmap is not the way to increase some speed. What needs to be
> done to provide a higher Qemu+KQEMU performance, comparable to
> VMPlayer? How does VMPlayer manage to be so much faster than Qemu? Is
> this simply an I/O bottleneck? How would I go about finding out what
> the differences are and how we can improve Qemu+KQEMU performance?
A copy of the kqemu source would be a good start.
Paul
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-14 16:45 ` Paul Brook
@ 2006-12-15 16:21 ` Joseph Miller
2006-12-15 16:13 ` Paul Brook
2006-12-15 16:32 ` [Qemu-devel] using mmap? Mark Williamson
1 sibling, 1 reply; 29+ messages in thread
From: Joseph Miller @ 2006-12-15 16:21 UTC (permalink / raw)
To: qemu-devel
Paul Brook wrote:
>> Does anyone know the reason for the removal of the mmap()? I have used
>> a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the
>> memory access in the guest WinXP was slooooooow. Does anyone have any
>> insight on making the hardware MMU function for linux-x86 host to WinXP
>> 32-bit guest, even partially?
>>
>
> As I already said, the code required a modified guest OS. i.e. it wouldn't
> work with windows guests anyway.
>
> It was removed because it provided very little benefit, and wasn't worth the
> effort to keep it working. Its uses were very specialised, and IMHO better
> covered by other products like UML or xen.
>
> I'm also doubtful how much benefit it gave in practice. I'm sure it would be
> good for synthetic CPU benchmarks. However using mmap significantly increases
> the overhead of context switches/tlb misses.
>
> To get good overall performance I suspect you're going to need closer
> cooperation with the kernel than mmap gives you. If you really want to make
> cross-emulation go fast I suggest working with the xen and/or kvm people to
> integrate qemu dynamic translation into those products. In theory I'd guess
> you should be able to plug it in as an alternative to the HVM code. I've no
> idea how close that is to being practical.
>
>
>> Wouldn't this be a *significant*
>> performance enhancement for this setup which I'm sure is a common one?
>> Maybe this can be implemented for regular processes on the guest and
>> only use the softmmu for the kernel? Would someone point me in the
>> right direction for technical information? I have had to switch to
>> vmware free player until Qemu+KQEMU reaches a point of similar
>> performance, but I would really rather see Qemu advance further.
>>
>
> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as
> most code isn't run by qemu, it's virtualized by the accelerator. qemu just
> does the IO emulation.
>
> Paul
>
OK, so mmap is not the way to increase some speed. What needs to be
done to provide a higher Qemu+KQEMU performance, comparable to
VMPlayer? How does VMPlayer manage to be so much faster than Qemu? Is
this simply an I/O bottleneck? How would I go about finding out what
the differences are and how we can improve Qemu+KQEMU performance?
-Joseph
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] using mmap?
2006-12-14 16:45 ` Paul Brook
2006-12-15 16:21 ` [Qemu-devel] Qemu speed vs vmplayer? Joseph Miller
@ 2006-12-15 16:32 ` Mark Williamson
2006-12-15 21:22 ` [Qemu-devel] " Anthony Liguori
1 sibling, 1 reply; 29+ messages in thread
From: Mark Williamson @ 2006-12-15 16:32 UTC (permalink / raw)
To: qemu-devel; +Cc: Paul Brook
> I'm also doubtful how much benefit it gave in practice. I'm sure it would
> be good for synthetic CPU benchmarks. However using mmap significantly
> increases the overhead of context switches/tlb misses.
>
> To get good overall performance I suspect you're going to need closer
> cooperation with the kernel than mmap gives you. If you really want to make
> cross-emulation go fast I suggest working with the xen and/or kvm people to
> integrate qemu dynamic translation into those products. In theory I'd guess
> you should be able to plug it in as an alternative to the HVM code. I've no
> idea how close that is to being practical.
http://wiki.xensource.com/xenwiki/HVM/V2E
The v2e stuff allows execution state to be extracted from the real CPU,
plugged into QEmu for a bit for emulation, then transferred back to the real
CPU again. This is initially to be used for supporting Big Real Mode
emulation on HVM platforms. Later on it's planned to be used to accelerate
IO emulation further.
Eventually this may provide a means to use QEmu's translator to execute kernel
code whilst running user mode code under Xen. It may be that this isn't as
fast as other approaches, but it'd be a useful feature for Xen to have IMO.
Cheers,
Mark
> > Wouldn't this be a *significant*
> > performance enhancement for this setup which I'm sure is a common one?
> > Maybe this can be implemented for regular processes on the guest and
> > only use the softmmu for the kernel? Would someone point me in the
> > right direction for technical information? I have had to switch to
> > vmware free player until Qemu+KQEMU reaches a point of similar
> > performance, but I would really rather see Qemu advance further.
>
> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as
> most code isn't run by qemu, it's virtualized by the accelerator. qemu just
> does the IO emulation.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Qemu-devel] Re: using mmap?
2006-12-15 16:32 ` [Qemu-devel] using mmap? Mark Williamson
@ 2006-12-15 21:22 ` Anthony Liguori
0 siblings, 0 replies; 29+ messages in thread
From: Anthony Liguori @ 2006-12-15 21:22 UTC (permalink / raw)
To: qemu-devel; +Cc: Paul Brook
Mark Williamson wrote:
>> I'm also doubtful how much benefit it gave in practice. I'm sure it would
>> be good for synthetic CPU benchmarks. However using mmap significantly
>> increases the overhead of context switches/tlb misses.
>>
>> To get good overall performance I suspect you're going to need closer
>> cooperation with the kernel than mmap gives you. If you really want to make
>> cross-emulation go fast I suggest working with the xen and/or kvm people to
>> integrate qemu dynamic translation into those products. In theory I'd guess
>> you should be able to plug it in as an alternative to the HVM code. I've no
>> idea how close that is to being practical.
>
> http://wiki.xensource.com/xenwiki/HVM/V2E
>
> The v2e stuff allows execution state to be extracted from the real CPU,
> plugged into QEmu for a bit for emulation, then transferred back to the real
> CPU again. This is initially to be used for supporting Big Real Mode
> emulation on HVM platforms. Later on it's planned to be used to accelerate
> IO emulation further.
>
> Eventually this may provide a means to use QEmu's translator to execute kernel
> code whilst running user mode code under Xen. It may be that this isn't as
> fast as other approaches, but it'd be a useful feature for Xen to have IMO.
I'd absolute like to get there. The current Xen HVM code is a bit of a
mess at the moment. There are far too many assumptions about having
VT/SVM hardware present. However, I'd really like to get to a point
where Xen could run unmodified guests on non VT/SVM hardware using qemu
with user virtualization.
KVM is having similar trouble ATM with big real mode. It would be very
nice to also add a V2E like interface to KVM.
I'd also like to see the translator even used for paravirtual guests.
This way we could still have a proper boot loader run without having to
deal with paravirtualizing it. It would be nice to use emulation to
avoid paravirtualizing the non-performance critical bits.
Regards,
Anthony Liguori
> Cheers,
> Mark
>
>>> Wouldn't this be a *significant*
>>> performance enhancement for this setup which I'm sure is a common one?
>>> Maybe this can be implemented for regular processes on the guest and
>>> only use the softmmu for the kernel? Would someone point me in the
>>> right direction for technical information? I have had to switch to
>>> vmware free player until Qemu+KQEMU reaches a point of similar
>>> performance, but I would really rather see Qemu advance further.
>> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as
>> most code isn't run by qemu, it's virtualized by the accelerator. qemu just
>> does the IO emulation.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 22:20 ` Joseph Miller
@ 2006-12-15 21:33 ` Lonnie Mendez
2006-12-15 21:38 ` Paul Brook
[not found] ` <Pine.LNX.4.64.0612160028590.758@home.oyster.ru>
2 siblings, 0 replies; 29+ messages in thread
From: Lonnie Mendez @ 2006-12-15 21:33 UTC (permalink / raw)
To: qemu-devel
On Fri, 2006-12-15 at 17:20 -0500, Joseph Miller wrote:
> I've got a copy of today's CVS, I was just assuming, since this is the
> qemu-devel mailing list, that someone on the list who regularly works on
> the qemu code would probably know more about this than I do. I have
> some assembly background, and I'm not afraid to start digging into x86
> cpu internals, but I would like a starting point. I'm really trying to
> figure out something specific about qemu. When running Qemu+KQEMU for
> linux-x86 host on WinXP x86 guest, top shows that 70% or more of my cpu
> is being use in the system portion. When using vmplayer (free), top
> shows less than 5% of my cpu in the system portion. vmplayer seems to
> be a LOT faster than Qemu, however I would prefer to use Qemu. I have a
> P4 2.6GHz host system with 1.5G RAM and 512MB RAM allocated to my guest
> OS's. Does anyone know the reason behind the slowdown? Is anyone
> familiar with what Qemu is so busy doing whilst sitting idle? I should
> note that I have compiled the KQemu into my 2.6 kernel instead of
> loading it as a module. I have found better performance with it this
> way. Any insight from a developer would be most appreciated.
Are you using the -kernel-kqemu switch? I see idle usage of 6-10% with
kqemu using -kernel-kqemu on windows xp guest. kqemu is closed source
software. If you want a starting point for improving the acceleration
portion then start by improving qvm86 (the GPL'ed accelerator).
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 22:20 ` Joseph Miller
2006-12-15 21:33 ` Lonnie Mendez
@ 2006-12-15 21:38 ` Paul Brook
2006-12-15 21:48 ` Christian MICHON
[not found] ` <Pine.LNX.4.64.0612160028590.758@home.oyster.ru>
2 siblings, 1 reply; 29+ messages in thread
From: Paul Brook @ 2006-12-15 21:38 UTC (permalink / raw)
To: qemu-devel
On Friday 15 December 2006 22:20, Joseph Miller wrote:
> Paul Brook wrote:
> >>> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
> >>> as most code isn't run by qemu, it's virtualized by the accelerator.
> >>> qemu just does the IO emulation.
> >>>
> >>> Paul
> >>
> >> OK, so mmap is not the way to increase some speed. What needs to be
> >> done to provide a higher Qemu+KQEMU performance, comparable to
> >> VMPlayer? How does VMPlayer manage to be so much faster than Qemu? Is
> >> this simply an I/O bottleneck? How would I go about finding out what
> >> the differences are and how we can improve Qemu+KQEMU performance?
> >
> > A copy of the kqemu source would be a good start.
>
> I've got a copy of today's CVS,
You missed my point entirely. kqemu is a closed source module, there's
absolutely nothing we can do with it.
Paul
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 21:38 ` Paul Brook
@ 2006-12-15 21:48 ` Christian MICHON
2006-12-15 21:57 ` Lonnie Mendez
2006-12-15 22:18 ` Paul Brook
0 siblings, 2 replies; 29+ messages in thread
From: Christian MICHON @ 2006-12-15 21:48 UTC (permalink / raw)
To: qemu-devel
On 12/15/06, Paul Brook <paul@codesourcery.com> wrote:
> > I've got a copy of today's CVS,
>
> You missed my point entirely. kqemu is a closed source module, there's
> absolutely nothing we can do with it.
>
well, we can use kqemu at least, right? :)
interesting benchmark: I started removing most of the graphics code
(which I originally believed was slowing down qemu a lot) and started
running through ssh on windows host + tap-win32 patch.
Using kqemu, I see no improvement in calculations, meaning the
graphical part (sdl) is not the main blocking point. Next on my
list of trials is the disk/io (we did some pthread experiment in the
past, I think we can get some more bandwith here).
one last point: last time I used qvm86 for windows host, it did
not give good results. Hanged OS, several reboots, qemu
hanging forever. And back then I was using up to date qvm86
cvs. Is qvm86 still active ? If yes (for windows host), I'll try to
do newer benchmarks.
--
Christian
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 21:48 ` Christian MICHON
@ 2006-12-15 21:57 ` Lonnie Mendez
2006-12-15 22:18 ` Paul Brook
1 sibling, 0 replies; 29+ messages in thread
From: Lonnie Mendez @ 2006-12-15 21:57 UTC (permalink / raw)
To: qemu-devel
On Fri, 2006-12-15 at 22:48 +0100, Christian MICHON wrote:
> Using kqemu, I see no improvement in calculations, meaning the
> graphical part (sdl) is not the main blocking point. Next on my
> list of trials is the disk/io (we did some pthread experiment in the
> past, I think we can get some more bandwith here).
Disk I/O on Linux and Freebsd hosts should be improved as qemu uses
AIO. The Windows build has stubs for the async routines.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 21:48 ` Christian MICHON
2006-12-15 21:57 ` Lonnie Mendez
@ 2006-12-15 22:18 ` Paul Brook
2006-12-15 22:34 ` Christian MICHON
1 sibling, 1 reply; 29+ messages in thread
From: Paul Brook @ 2006-12-15 22:18 UTC (permalink / raw)
To: qemu-devel
On Friday 15 December 2006 21:48, Christian MICHON wrote:
> On 12/15/06, Paul Brook <paul@codesourcery.com> wrote:
> > > I've got a copy of today's CVS,
> >
> > You missed my point entirely. kqemu is a closed source module, there's
> > absolutely nothing we can do with it.
>
> well, we can use kqemu at least, right? :)
QEMU is an open source project (and this list is hosted on a site that is
explicitly for open source projects)· Thus any solution that involves
proprietary closed source modules is offtopic.
Paul
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 16:13 ` Paul Brook
@ 2006-12-15 22:20 ` Joseph Miller
2006-12-15 21:33 ` Lonnie Mendez
` (2 more replies)
2006-12-16 5:27 ` [Qemu-devel] Qemu speed vs vmplayer? Jamie Lokier
1 sibling, 3 replies; 29+ messages in thread
From: Joseph Miller @ 2006-12-15 22:20 UTC (permalink / raw)
To: qemu-devel
Paul Brook wrote:
>>> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
>>> as most code isn't run by qemu, it's virtualized by the accelerator. qemu
>>> just does the IO emulation.
>>>
>>> Paul
>>>
>> OK, so mmap is not the way to increase some speed. What needs to be
>> done to provide a higher Qemu+KQEMU performance, comparable to
>> VMPlayer? How does VMPlayer manage to be so much faster than Qemu? Is
>> this simply an I/O bottleneck? How would I go about finding out what
>> the differences are and how we can improve Qemu+KQEMU performance?
>>
>
> A copy of the kqemu source would be a good start.
>
> Paul
>
I've got a copy of today's CVS, I was just assuming, since this is the
qemu-devel mailing list, that someone on the list who regularly works on
the qemu code would probably know more about this than I do. I have
some assembly background, and I'm not afraid to start digging into x86
cpu internals, but I would like a starting point. I'm really trying to
figure out something specific about qemu. When running Qemu+KQEMU for
linux-x86 host on WinXP x86 guest, top shows that 70% or more of my cpu
is being use in the system portion. When using vmplayer (free), top
shows less than 5% of my cpu in the system portion. vmplayer seems to
be a LOT faster than Qemu, however I would prefer to use Qemu. I have a
P4 2.6GHz host system with 1.5G RAM and 512MB RAM allocated to my guest
OS's. Does anyone know the reason behind the slowdown? Is anyone
familiar with what Qemu is so busy doing whilst sitting idle? I should
note that I have compiled the KQemu into my 2.6 kernel instead of
loading it as a module. I have found better performance with it this
way. Any insight from a developer would be most appreciated.
-Joseph
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 22:18 ` Paul Brook
@ 2006-12-15 22:34 ` Christian MICHON
2006-12-15 22:47 ` Paul Brook
0 siblings, 1 reply; 29+ messages in thread
From: Christian MICHON @ 2006-12-15 22:34 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
On 12/15/06, Paul Brook <paul@codesourcery.com> wrote:
> QEMU is an open source project (and this list is hosted on a site that is
> explicitly for open source projects)· Thus any solution that involves
> proprietary closed source modules is offtopic.
>
ok, politically incorrect. point taken :)
yet, what about the second part of my reply ?
Is qvm86 still active ? if yes, great. if no, what do you need to restart it ?
(else than dedicated developpers, of course). As far as I can see, no
qvm86 check-in for 15 months now...
--
Christian
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 22:34 ` Christian MICHON
@ 2006-12-15 22:47 ` Paul Brook
0 siblings, 0 replies; 29+ messages in thread
From: Paul Brook @ 2006-12-15 22:47 UTC (permalink / raw)
To: qemu-devel
> Is qvm86 still active ? if yes, great. if no, what do you need to restart
> it ? (else than dedicated developpers, of course). As far as I can see, no
> qvm86 check-in for 15 months now...
Not really. I haven't had chance to do anything with it for a while, and
probably won't in the forseeable future. It probably wouldn't take more than
a couple of weeks work for an experienced coder to get it working properly.
If someone else shows serious interest in qvm86 I've no real objection to
handing over management of the project to them.
As Anthony mentioned, efforts might be best spent integrating this
functionality into Xen or KVM. You're more than welcome to use qvm86 code for
this.
Paul
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-15 16:13 ` Paul Brook
2006-12-15 22:20 ` Joseph Miller
@ 2006-12-16 5:27 ` Jamie Lokier
1 sibling, 0 replies; 29+ messages in thread
From: Jamie Lokier @ 2006-12-16 5:27 UTC (permalink / raw)
To: qemu-devel
Paul Brook wrote:
> > OK, so mmap is not the way to increase some speed. What needs to be
> > done to provide a higher Qemu+KQEMU performance, comparable to
> > VMPlayer? How does VMPlayer manage to be so much faster than Qemu? Is
> > this simply an I/O bottleneck? How would I go about finding out what
> > the differences are and how we can improve Qemu+KQEMU performance?
>
> A copy of the kqemu source would be a good start.
As would reading VMware peoples' publications on the tricks they've
used. I'm thinking of a paper which compares VMware's performance on
hardware VM (newer Intel/AMD) versus software VM, and finds software
is actually faster in many cases. It happens to mention in passing a
lot of tricks used by VMware.
-- Jamie
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
[not found] ` <Pine.LNX.4.64.0612161732560.630@home.oyster.ru>
@ 2006-12-17 4:37 ` it
2006-12-17 5:18 ` Lonnie Mendez
0 siblings, 1 reply; 29+ messages in thread
From: it @ 2006-12-17 4:37 UTC (permalink / raw)
To: qemu-devel
> On Sat, 16 Dec 2006, it@tidetamerboatlifts.com wrote:
>
>>> On Fri, 15 Dec 2006, Joseph Miller wrote:
>
> [..snip..]
>
>> Malc,
>>
>> Thanks,
>> I think that this was my problem. I didn't realize that the usb tablet
>> would cause such a slowdown. The usb tablet is such a useful feature,
>> I'm
>> sure it is commonly used. Maybe a warning could be provided so that
>> users
>> would know it has some performance quirks. Maybe I can look at the code
>> and find out why it is so much slower? Maybe this is a general usb
>> problem?
>
> You think? As in: tried with and without USB and top reports much higher
> CPU usage? In any case do not rely on top(1) too much, as mentioned in
> the post for certain CPU usage patterns Linux just does not provide a
> meaningful idleness information (which top uses).
>
> Again as mentioned in the post, i have seen 30%-40% difference between
> "real" idleness and what the kernel reports via proc, but 70% is a bit
> too much. The negative impact of USB (tablet only?) on the load was
> mentioned a few times on the ML and in private conversations with
> Anthony Liguori and since there was no progress in this area i doubt
> that there's much you can do apart from reporting the issue once again.
>
> Apparently you wont find much symphaty when reporting the speed issues
> while kqemu is active. So i'd suggest to:
>
> a. Measure and report the difference without kqemu
> b. Use something more reliable than top(1)
>
> --
> vale
>
Yeah, I said "I think" because I wanted to use a decent benchmark to
actually test the results. I threw in a test against VMPlayer as well. I
found that with USB tablet emulation, Qemu was approximately only half as
fast as it could operate without it. I did NOT perform these tests
without KQEMU for two reasons 1) the *concept* that USB tablet emulation
slows down Qemu can be shown either way and 2) I can't stand waiting
around for hours and hours while Qemu translates code, sorry. At this
particular time, I'm really only interested in this particular case
because I use it for production use and many non-developer users are
wanting to do the same thing. The only major difference that I found
between Qemu+KQEMU and VMPlayer was that VMPlayer is about 4x faster when
it comes to memory access. You can view my results at:
http://www.calcmaster.net/qemu/benchmarks-20061216/
-Joseph
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed vs vmplayer?
2006-12-17 4:37 ` it
@ 2006-12-17 5:18 ` Lonnie Mendez
2006-12-19 16:00 ` [Qemu-devel] Qemu speed w/ USB tablet emulation Joseph Miller
0 siblings, 1 reply; 29+ messages in thread
From: Lonnie Mendez @ 2006-12-17 5:18 UTC (permalink / raw)
To: qemu-devel
On Sat, 2006-12-16 at 23:37 -0500, it@tidetamerboatlifts.com wrote:
> Yeah, I said "I think" because I wanted to use a decent benchmark to
> actually test the results. I threw in a test against VMPlayer as well. I
> found that with USB tablet emulation, Qemu was approximately only half as
> fast as it could operate without it. I did NOT perform these tests
> without KQEMU for two reasons 1) the *concept* that USB tablet emulation
> slows down Qemu can be shown either way and 2) I can't stand waiting
> around for hours and hours while Qemu translates code, sorry. At this
> particular time, I'm really only interested in this particular case
> because I use it for production use and many non-developer users are
> wanting to do the same thing. The only major difference that I found
> between Qemu+KQEMU and VMPlayer was that VMPlayer is about 4x faster when
> it comes to memory access. You can view my results at:
>
> http://www.calcmaster.net/qemu/benchmarks-20061216/
Two things:
1. http://www.vmware.com/download/eula/player.html
(Restrictions - Section 3.3 - "You may use the Software to ...")
2. http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00360.html
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Qemu-devel] Qemu speed w/ USB tablet emulation
2006-12-17 5:18 ` Lonnie Mendez
@ 2006-12-19 16:00 ` Joseph Miller
0 siblings, 0 replies; 29+ messages in thread
From: Joseph Miller @ 2006-12-19 16:00 UTC (permalink / raw)
To: qemu-devel
Lonnie Mendez wrote:
> On Sat, 2006-12-16 at 23:37 -0500, it@tidetamerboatlifts.com wrote:
>
>> Yeah, I said "I think" because I wanted to use a decent benchmark to
>> actually test the results. I threw in a test against VMPlayer as well. I
>> found that with USB tablet emulation, Qemu was approximately only half as
>> fast as it could operate without it. I did NOT perform these tests
>> without KQEMU for two reasons 1) the *concept* that USB tablet emulation
>> slows down Qemu can be shown either way and 2) I can't stand waiting
>> around for hours and hours while Qemu translates code, sorry. At this
>> particular time, I'm really only interested in this particular case
>> because I use it for production use and many non-developer users are
>> wanting to do the same thing. The only major difference that I found
>> between Qemu+KQEMU and VMPlayer was that VMPlayer is about 4x faster when
>> it comes to memory access. You can view my results at:
>>
>> http://www.calcmaster.net/qemu/benchmarks-20061216/
>>
>
> Two things:
>
> 1. http://www.vmware.com/download/eula/player.html
> (Restrictions - Section 3.3 - "You may use the Software to ...")
>
> 2. http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00360.html
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
I have tested and benchmarked this USB tablet emulation patch from
http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00360.html on my
website at http://www.calcmaster.net/qemu/benchmarks-20061216/ and you
can see that this patch makes a HUGE difference in performance. Is
there any way that this patch could be committed any time soon?
-Joseph
P.S. Any insight on why Qemu's memory access is so much slower than a
vmplayer? Fabrice?
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2006-12-19 22:36 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-13 8:09 [Qemu-devel] About performance of qemu-system-arm PianoPan
2006-12-13 10:32 ` [Qemu-devel] " Ross Burton
2006-12-13 11:22 ` [Qemu-devel] " Màrius Montón
2006-12-13 14:17 ` PianoPan
2006-12-13 15:23 ` Màrius Montón
2006-12-13 13:26 ` Martin Guy
2006-12-13 14:40 ` [Qemu-devel] qemu-system-* using mmap? Tim Olson
2006-12-13 15:32 ` Paul Brook
2006-12-13 16:04 ` Joseph Miller
2006-12-14 14:50 ` Tim Olson
2006-12-14 17:01 ` [Qemu-devel] " Joseph Miller
2006-12-14 16:45 ` Paul Brook
2006-12-15 16:21 ` [Qemu-devel] Qemu speed vs vmplayer? Joseph Miller
2006-12-15 16:13 ` Paul Brook
2006-12-15 22:20 ` Joseph Miller
2006-12-15 21:33 ` Lonnie Mendez
2006-12-15 21:38 ` Paul Brook
2006-12-15 21:48 ` Christian MICHON
2006-12-15 21:57 ` Lonnie Mendez
2006-12-15 22:18 ` Paul Brook
2006-12-15 22:34 ` Christian MICHON
2006-12-15 22:47 ` Paul Brook
[not found] ` <Pine.LNX.4.64.0612160028590.758@home.oyster.ru>
[not found] ` <25199.71.51.225.120.1166272989.squirrel@secure.emarketingnc.com>
[not found] ` <Pine.LNX.4.64.0612161732560.630@home.oyster.ru>
2006-12-17 4:37 ` it
2006-12-17 5:18 ` Lonnie Mendez
2006-12-19 16:00 ` [Qemu-devel] Qemu speed w/ USB tablet emulation Joseph Miller
2006-12-16 5:27 ` [Qemu-devel] Qemu speed vs vmplayer? Jamie Lokier
2006-12-15 16:32 ` [Qemu-devel] using mmap? Mark Williamson
2006-12-15 21:22 ` [Qemu-devel] " Anthony Liguori
2006-12-13 15:10 ` [Qemu-devel] About performance of qemu-system-arm Martin Guy
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).