2011/8/2 Kevin Wolf <kw...@redhat.com>: > 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. >
Did I send patches for qcow2? I just rebased them with your last updates, I'll send them again. > 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 > > Frediano
