From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48665 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiPIY-0001xW-42 for qemu-devel@nongnu.org; Thu, 27 Jan 2011 05:41:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiPIV-0004TS-P1 for qemu-devel@nongnu.org; Thu, 27 Jan 2011 05:41:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiPIV-0004T8-Hq for qemu-devel@nongnu.org; Thu, 27 Jan 2011 05:41:51 -0500 Message-ID: <4D414BE9.5010103@redhat.com> Date: Thu, 27 Jan 2011 12:41:45 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH 11/12] qcow2: Convert qcow2 to use coroutines for async I/O References: <1295688567-25496-1-git-send-email-stefanha@linux.vnet.ibm.com> <1295688567-25496-12-git-send-email-stefanha@linux.vnet.ibm.com> <4D40406B.2070302@redhat.com> <4D4042A8.2040903@redhat.com> <4D4046EF.3050108@codemonkey.ws> <4D40481E.9040309@redhat.com> <4D404B9F.7040801@codemonkey.ws> <4D404E1F.50809@redhat.com> <4D4055FB.6090104@codemonkey.ws> <4D413A88.2060204@redhat.com> <4D413F98.4010205@redhat.com> <4D414A51.4080601@redhat.com> In-Reply-To: <4D414A51.4080601@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , qemu-devel@nongnu.org On 01/27/2011 12:34 PM, Kevin Wolf wrote: > Am 27.01.2011 10:49, schrieb Avi Kivity: > > On 01/27/2011 11:27 AM, Kevin Wolf wrote: > >> Well, but in the case of qcow2, you don't want to have a big mutex > >> around everything. We perfectly know which parts are asynchronous and > >> which are synchronous, so we'd want to do it finer grained from the > >> beginning. > > > > Yes we do. And the way I proposed it, the new mutex does not introduce > > any new serialization. > > > > To repeat, for every qcow2 callback or completion X (not qcow2 read or > > write operation), we transform it in the following manner: > > [...] > > This works fine for code that is completely synchronous today (and you > can't serialize it more than it already is anyway). > > It doesn't work for qemu_aio_readv/writev because these use AIO for > reading/writing the data. So you definitely need to rewrite that part, > or the AIO callback will cause the code to run outside its coroutine. The callbacks need to be wrapped in the same way. Schedule a coroutine to run the true callback. > And during this rewrite you'll want to pay attention that you don't hold > the mutex for the bdrv_co_readv that was an AIO request before, or > you'll introduce additional serialization. I don't follow. Please elaborate. The idea behind this is, we keep exactly the same serialization characteristics we had before. If a aio_X callback or its intermediate completion executed without blocking, it will continue to do so. Holding a co_mutex over a non-blocking code sequence does not serialize, except if a blocking sequence is executing concurrently (in which case the serialization was present before). -- error compiling committee.c: too many arguments to function