From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G55SK-00058Q-71 for qemu-devel@nongnu.org; Mon, 24 Jul 2006 14:47:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G55SJ-00057q-HJ for qemu-devel@nongnu.org; Mon, 24 Jul 2006 14:47:03 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G55SJ-00057n-FW for qemu-devel@nongnu.org; Mon, 24 Jul 2006 14:47:03 -0400 Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G55TS-0001WY-9q for qemu-devel@nongnu.org; Mon, 24 Jul 2006 14:48:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G55SC-0002Gd-VN for qemu-devel@nongnu.org; Mon, 24 Jul 2006 20:46:56 +0200 Received: from cpe-70-116-9-243.austin.res.rr.com ([70.116.9.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Jul 2006 20:46:56 +0200 Received: from anthony by cpe-70-116-9-243.austin.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Jul 2006 20:46:56 +0200 From: Anthony Liguori Date: Mon, 24 Jul 2006 13:46:40 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Sender: news Subject: [Qemu-devel] Re: high CPU load / async IO? 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 On Mon, 24 Jul 2006 00:47:21 +0200, Sven Köhler wrote: > 3) async block I/O (not merged yet) > It's not in HEAD yet, isn't it? The pthread-based async patch is a band-aid. No doubt it helps your particular case, but it's not the right approach long term. IDE only supports one outstanding request, so having a thread that runs the synchronous block routines appears reasonable. However, SATA and SCSI both support multiple outstanding requests. The extension to the existing patch would be simple--increase the number of threads. A number of Xen hackers (primarily Andy Warfield and Dan Smith) have been doing a lot of work analyzing userspace block device performance. As QEMU's CPU virtualization gets faster (ala kqemu or VT/SVM), it will start facing the same bottlenecks that we do today in Xen. To achieve near-native performance, you basically have to be able to saturate the host's IO scheduler queue. Using O_DIRECT, you can do zero-copy meaning that your ability to queue requests is the only limiting factor. What's been discovered is that a thread based approach requires a ton of threads to achieve saturation. Just imagine the contention of having a very large number of threads trying to get at a single BDRVState. The real solution is to modify the block API to be asynchronous and then provide support for interacting with the host IO scheduler queue via something like linux-aio (or the win32 equiv). So the current thread-based async dma patch is really just the wrong long term solution. A more long term solution is likely in the works. It requires quite a bit of code modification though. Regards, Anthony Liguori > Why i'm curious? Well, i'm curious about the improvement it causes. You > people once told me, that the boost will not be that significant. On the > other hand, i see my host CPU usage going towards 100% just because the > guest is doing some IO or ... or is it because of somethine else > perhaps? > > To be concrete: have you guys ever run windows-update inside qemu? Well, > my win2k guest consumes all CPU on the host for some reason. What might > be the reason? > (qemu is started with -kernel-kqemu -m 256 -soundhw es1370) > > Also windows-update's green "progress bar" inside the guest is stopping > for let's say 3 or 5 seconds and not moving continuous. > > Is anybody experiencing the same or knows the reason? > > > Thanks, > Sven > _______________________________________________ Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel