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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel