qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Mon, 13 Sep 2010 12:41:02 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]