From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32847 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkGBT-0002Ng-0j for qemu-devel@nongnu.org; Tue, 01 Feb 2011 08:22:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkGBR-0007S6-CR for qemu-devel@nongnu.org; Tue, 01 Feb 2011 08:22:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkGBR-0007RP-5E for qemu-devel@nongnu.org; Tue, 01 Feb 2011 08:22:13 -0500 Message-ID: <4D480967.3030205@redhat.com> Date: Tue, 01 Feb 2011 14:23:51 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH 00/12] qcow2: Convert qcow2 to use coroutines for async I/O References: <1295688567-25496-1-git-send-email-stefanha@linux.vnet.ibm.com> <4D3CBA6D.8010506@codemonkey.ws> In-Reply-To: <4D3CBA6D.8010506@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , qemu-devel@nongnu.org Am 24.01.2011 00:31, schrieb Anthony Liguori: > On 01/22/2011 03:29 AM, Stefan Hajnoczi wrote: >> This patch series prototypes making QCOW2 fully asynchronous to eliminate the >> timing jitter and poor performance that has been observed. QCOW2 has >> asynchronous I/O code paths for some of the read/write common cases but >> metadata access is always synchronous. >> >> One solution is to rewrite QCOW2 to be fully asynchronous by splitting all >> functions that perform blocking I/O into a series of callbacks. Due to the >> complexity of QCOW2, this conversion and the maintenance prospects are >> unattractive. >> >> This patch series prototypes an alternative solution to make QCOW2 >> asynchronous. It introduces coroutines, cooperative userspace threads of >> control, so that each QCOW2 request has its own call stack. To perform I/O, >> the coroutine submits an asynchronous I/O request and then yields back to QEMU. >> The coroutine stays suspended while the I/O operation is being processed by >> lower layers of the stack. When the asynchronous I/O completes, the coroutine >> is resumed. >> >> The upshot of this is that QCOW2 can be implemented in a sequential fashion >> without explicit callbacks but all I/O actually happens asynchronously under >> the covers. >> >> This prototype implements reads, writes, and flushes. Should install or boot >> VMs successfully. However, it has the following limitations: >> >> 1. QCOW2 requests are serialized because the code is not yet safe for >> concurrent requests. See the last patch for details. >> >> 2. Coroutines are unoptimized. We should pool coroutines (and their mmapped >> stacks) to avoid the cost of coroutine creation. >> >> 3. The qcow2_aio_read_cb() and qcow2_aoi_write_cb() functions should be >> refactored into sequential code now that callbacks are no longer needed. >> >> I think this approach can solve the performance and functional problems of the >> current QCOW2 implementation. It does not require invasive changes, much of >> QCOW2 works unmodified. >> >> Kevin: Do you like this approach and do you want to develop it further? >> > > Couple of additional comments: > > 1) The coroutine code is copied in a number of projects. I plan on > splitting it into a shared library. When are you going to do so? Should we wait with using coroutines in qemu until then or just start with maintaining a copy and remove it later? I think we'll have to carry a copy of the library in the qemu source anyway for a while if we depend on it and distributions don't have a package for the library yet. Kevin