From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35581 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ov6Sw-0005Vk-Sx for qemu-devel@nongnu.org; Mon, 13 Sep 2010 06:40:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ov6Sv-0006fS-29 for qemu-devel@nongnu.org; Mon, 13 Sep 2010 06:40:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46725) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov6Su-0006fD-RT for qemu-devel@nongnu.org; Mon, 13 Sep 2010 06:40:49 -0400 Message-ID: <4C8DFFBE.7010108@redhat.com> Date: Mon, 13 Sep 2010 12:41:02 +0200 From: Kevin Wolf 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> <4C8A8809.3060900@codemonkey.ws> In-Reply-To: <4C8A8809.3060900@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: qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi Am 10.09.2010 21:33, schrieb Anthony Liguori: > 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. Without a cache miss, qcow2_aio_readv/writev is a lookup in an array (the L2 table) and then directly translated into a raw_aio_readv/writev. So I don't see any reason why it shouldn't handle requests in parallel. > Does any meta data cache miss (read or write) cause a stall/flush of the > request queue? Metadata reads mean that we do a synchronous bdrv_pread and block the caller for this time. I think the caller is either the device model or the processing of AIO callbacks. So I guess effectively this is what you called a stall. Kevin