From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E9out-00065K-OZ for qemu-devel@nongnu.org; Mon, 29 Aug 2005 15:03:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E9ouh-0005yD-1C for qemu-devel@nongnu.org; Mon, 29 Aug 2005 15:03:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E9oug-0005ug-2x for qemu-devel@nongnu.org; Mon, 29 Aug 2005 15:03:22 -0400 Received: from [69.17.117.24] (helo=mail22.sea5.speakeasy.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1E9ooD-0001QE-L3 for qemu-devel@nongnu.org; Mon, 29 Aug 2005 14:56:42 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) ([64.81.88.222]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 29 Aug 2005 18:53:15 -0000 Subject: Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows. From: "John R. Hogerhuis" In-Reply-To: <20050829180505.84705.qmail@web50512.mail.yahoo.com> References: <20050829180505.84705.qmail@web50512.mail.yahoo.com> Content-Type: text/plain Date: Mon, 29 Aug 2005 11:53:26 -0700 Message-Id: <1125341607.28382.28.camel@aragorn> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, 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 On Mon, 2005-08-29 at 11:05 -0700, Francois Rioux wrote: > I notice that QEMU is quite slower than VMWare. It certainly is. > Apparently due to the way IO occur. What are the strategies to > enhance that performance? Curious, why do you think that? There are probably a whole host of reasons that VmWare is faster, IO devices are only one part of the picture. The more interesting place for optimizations is on the dynamic code generation. VmWare is a virtualizer while QEMU employs a default strategy of dynamically generating direct (I think) threaded code. So the way to achieve improved speed is to improve the dynamic code generator. KQEMU presumably does this on X86 by inlining more of the original code with minimal changes (i.e more tokens containing bigger swaths of native code, and less simple instruction emulation tokens), so performance will be more like what you could expect from a virtualizer. KQEMU is not open source though, so if you want to fiddle with that, you probably would have to do it on qvm86. As to IO, one thought is to run a Windows X server (such as the free one that comes with Cygwin) natively on the host rather than under emulation. Do testing with tuntap networking. User-net networking is slow, Slirp code could certainly stand some bugfixes and optimizations. There are different tricks you can do to improve the experience. For example, avoid booting your virtual images from scratch. Boot to desktop, and savevm. Then in the future, boot straight off the savevm, it is much faster that way. -- John.