From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50945 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou9Lr-0008VJ-CI for qemu-devel@nongnu.org; Fri, 10 Sep 2010 15:33:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou9Lq-0007Oz-5O for qemu-devel@nongnu.org; Fri, 10 Sep 2010 15:33:35 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:51040) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou9Lq-0007Or-2u for qemu-devel@nongnu.org; Fri, 10 Sep 2010 15:33:34 -0400 Received: by vws19 with SMTP id 19so3047154vws.4 for ; Fri, 10 Sep 2010 12:33:33 -0700 (PDT) Message-ID: <4C8A8809.3060900@codemonkey.ws> Date: Fri, 10 Sep 2010 14:33:29 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84E738.3020802@codemonkey.ws> <4C865187.6090508@redhat.com> <4C865CFE.7010508@codemonkey.ws> <4C8663C4.1090508@redhat.com> <4C866773.2030103@codemonkey.ws> <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com> <4C88D7CC.5000806@codemonkey.ws> <4C8A1311.8070903@redhat.com> <4C8A2F40.7000509@codemonkey.ws> <4C8A36D4.5050001@redhat.com> <4C8A4707.7080705@codemonkey.ws> <4C8A5391.2030601@redhat.com> <4C8A65BB.9010602@codemonkey.ws> <4C8A6DEF.80508@redhat.com> In-Reply-To: <4C8A6DEF.80508@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: qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi On 09/10/2010 12:42 PM, Kevin Wolf wrote: >> It bounces all buffers still and I still think it's synchronous >> (although Kevin would know better). >> > Yes, it does bounce the buffers, though I'm looking into this anyway > because you raised concerns about unbounded allocations. (And it has > been on my todo list for a while, but there were always more urgent things) > > What's synchronous in qcow2 is metadata access and COW. The guest > requests themselves are handled asynchronously. I think we should differentiate between serialized requests and synchronous requests because I got a bit sloppy in my nomenclature. Metadata reads and writes along with COW operations are synchronous in qcow2 IIUC. The data read/write is asynchronous. Metadata is cached and if a cache hit is taken, then a full request can be asynchronous. It's not clear to me if qcow2 can handle parallel requests though assuming that both requests don't require a cache miss for meta data. Does any meta data cache miss (read or write) cause a stall/flush of the request queue? In QED, all operations are asynchronous including metadata cache misses and COW operations. Multiple requests are handled in parallel with the exception of metadata writes. A metadata write will stall all future metadata cache miss fulfillment but they remain asynchronous. Requests that can be satisfied from the cache will be executed in parallel though. In the future, we'll do something more sophisticated and allow multiple simultaneous metadata writes provided they aren't do the same L2/L1 location. Regards, Anthony Liguori