qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/10] block: Coroutine support


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 00/10] block: Coroutine support
Date: Tue, 02 Aug 2011 17:59:41 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

On 08/02/2011 05:50 PM, 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?).

That's what I meant. I just didn't review thoroughly - I saw some _cb suffixes and made incorrect assumptions.

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.

Ok, great.

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).

Usually completing is fine, but sometimes it cannot be made to work (networked or fabriced disk with no timeout or timeout greater than the device we're emulating).


However, there's no kernel interface for cancellation (it will usually be TASK_UNINTERRUPTIBLE) except for linux-aio. So I guess we can implement it only there.

--
error compiling committee.c: too many arguments to function




reply via email to

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