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

[Avi Kivity <avi@redhat.com>]

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