From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoGQu-0008Vd-JN for qemu-devel@nongnu.org; Tue, 02 Aug 2011 10:59:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoGQt-0006jt-L6 for qemu-devel@nongnu.org; Tue, 02 Aug 2011 10:59:00 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:42685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoGQt-0006jo-Di for qemu-devel@nongnu.org; Tue, 02 Aug 2011 10:58:59 -0400 Received: by ywb3 with SMTP id 3so1591797ywb.4 for ; Tue, 02 Aug 2011 07:58:58 -0700 (PDT) Message-ID: <4E3810AE.10201@codemonkey.ws> Date: Tue, 02 Aug 2011 09:58:54 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1311680948-7648-1-git-send-email-kwolf@redhat.com> <4E38084C.6010601@redhat.com> <4E380E9B.5090600@redhat.com> In-Reply-To: <4E380E9B.5090600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/10] block: Coroutine support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: stefanha@gmail.com, Avi Kivity , qemu-devel@nongnu.org On 08/02/2011 09:50 AM, Kevin Wolf wrote: > Am 02.08.2011 16:23, schrieb Avi Kivity: >> On 07/26/2011 02:48 PM, Kevin Wolf wrote: >>> Depends on Stefan's latest coroutine patches. This series makes qcow and qcow2 >>> take advantage of the new coroutine infrastructure. Both formats used >>> synchronous operations for accessing their metadata and blocked the guest CPU >>> during that time. With coroutines, the I/O will happen asynchronously in the >>> background and the CPU won't be blocked any more. >>> >> >> Do you plan to convert qcow2 to a fully synchronous design? >> >> IMO that will make it more maintainable. Cancellation will need some >> thought, though. > > After this patch series, all interesting paths are free of callbacks (I > assume this is what you mean by synchronous?). The only thing I can see > that is left is qcow2_aio_flush. What is required are some cleanups that > eliminate things that still look like AIO code, and yes, that's > something that I want to have. > > Frediano has posted some patches which I haven't fully reviewed yet, but > the qcow1 RFC he posted was definitely a step in the right direction. > > Regarding cancellation, I don't know any driver that really does what > it's supposed to do. There are basically two ways of implementing it in > current code: Either by completing the request instead of cancelling, or > it's broken. I'd suggest that we implement waiting for completion as a > generic function in the block layer and be done with it (actually this > is what happens with bdrv_aio_co_cancel_em, it just could be a bit finer > grained). If you introduce queuing at the generic layer, than removing from queue or waiting for completion is entirely acceptable semantics IMHO. Regards, Anthony Liguori > > Kevin >