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