From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GvFLP-0008RK-Tn for qemu-devel@nongnu.org; Fri, 15 Dec 2006 10:51:32 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GvFLP-0008QT-De for qemu-devel@nongnu.org; Fri, 15 Dec 2006 10:51:31 -0500 Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GvFLP-0006Ng-Gh for qemu-devel@nongnu.org; Fri, 15 Dec 2006 10:51:31 -0500 Received: from [69.69.215.43] (helo=mail.premiumoperatingsystems.net) by mx20.gnu.org with esmtp (Exim 4.52) id 1GvEt4-0004KJ-Nq for qemu-devel@nongnu.org; Fri, 15 Dec 2006 10:22:15 -0500 Received: from [192.168.2.30] (nc-71-48-24-78.dhcp.embarqhsd.net [71.48.24.78]) (authenticated bits=0) by mail.premiumoperatingsystems.net (8.12.11/8.12.11) with ESMTP id kBFFMAmD005619 for ; Fri, 15 Dec 2006 10:22:11 -0500 Message-ID: <4582CBA6.6000809@tidetamerboatlifts.com> Date: Fri, 15 Dec 2006 11:21:58 -0500 From: Joseph Miller MIME-Version: 1.0 Subject: Re: [Qemu-devel] Qemu speed vs vmplayer? References: <10541fa50612130009s798a1587n4a3d2b8b51baa334@mail.gmail.com> <799dfe3574a1e50e5a9a0da483b58db6@io.com> <4581836C.7080709@tidetamerboatlifts.com> <200612141645.40403.paul@codesourcery.com> In-Reply-To: <200612141645.40403.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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