[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/10] block: Coroutine support
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 00/10] block: Coroutine support |
Date: |
Tue, 02 Aug 2011 16:50:03 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 |
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).
Kevin