From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G59H0-0003t9-Ct for qemu-devel@nongnu.org; Mon, 24 Jul 2006 18:51:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G59Gy-0003sb-0F for qemu-devel@nongnu.org; Mon, 24 Jul 2006 18:51:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G59Gx-0003sY-QS for qemu-devel@nongnu.org; Mon, 24 Jul 2006 18:51:35 -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 1G59I8-0000fK-Qf for qemu-devel@nongnu.org; Mon, 24 Jul 2006 18:52:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G59Gv-0001xj-0W for qemu-devel@nongnu.org; Tue, 25 Jul 2006 00:51:33 +0200 Received: from dslb-084-061-137-081.pools.arcor-ip.net ([84.61.137.81]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Jul 2006 00:51:33 +0200 Received: from skoehler by dslb-084-061-137-081.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Jul 2006 00:51:33 +0200 From: =?ISO-8859-2?Q?Sven_K=F6hler?= Date: Tue, 25 Jul 2006 00:51:23 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8378F618D275880560102A08" In-Reply-To: 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8378F618D275880560102A08 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable >> 3) async block I/O (not merged yet) >> It's not in HEAD yet, isn't it? >=20 > 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. >=20 > IDE only supports one outstanding request, so having a thread that runs= > the synchronous block routines appears reasonable. However, SATA and S= CSI > both support multiple outstanding requests. The extension to the exist= ing > patch would be simple--increase the number of threads. ??? Wasn't there another variant using the async-I/O support of the Host OS and thereby supporting a larger number of outstanding requests? > A number of Xen hackers (primarily Andy Warfield and Dan Smith) have be= en > doing a lot of work analyzing userspace block device performance. As > QEMU's CPU virtualization gets faster (ala kqemu or VT/SVM), it will st= art > facing the same bottlenecks that we do today in Xen. >=20 > 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 limit= ing > factor. >=20 > What's been discovered is that a thread based approach requires a ton o= f > threads to achieve saturation. Just imagine the contention of having a= > very large number of threads trying to get at a single BDRVState. >=20 > The real solution is to modify the block API to be asynchronous and the= n > provide support for interacting with the host IO scheduler queue via > something like linux-aio (or the win32 equiv). The approch that i mentioned above (using the host's async I/O) is what you mean with using linux-aio, right? > So the current thread-based async dma patch is really just the wrong lo= ng > term solution. A more long term solution is likely in the works. It > requires quite a bit of code modification though. I see. So in other words: don't ask for simple async I/O now. The more complex and flexible sollution will follow soon. --------------enig8378F618D275880560102A08 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExU7r7Ww7FjRBE4ARAosWAJ9GaZuD3GC6lhtyA2vaavmBYso6pwCfcYLJ wdcNSjRY2go5EcU7XhvkKeI= =yvl4 -----END PGP SIGNATURE----- --------------enig8378F618D275880560102A08--