|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [RFC][PATCH 11/12] qcow2: Convert qcow2 to use coroutines for async I/O |
Date: | Wed, 26 Jan 2011 18:13:18 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 |
On 01/26/2011 06:08 PM, Anthony Liguori wrote:
On 01/26/2011 09:50 AM, Kevin Wolf wrote:Am 26.01.2011 16:40, schrieb Avi Kivity:On 01/22/2011 11:29 AM, Stefan Hajnoczi wrote:Converting qcow2 to use coroutines is fairly simple since most of qcow2is synchronous. The synchronous I/O functions likes bdrv_pread() nowtransparently work when called from a coroutine, so all the synchronouscode just works. The explicitly asynchronous code is adjusted to repeatedly callqcow2_aio_read_cb() or qcow2_aio_write_cb() until the request completes. At that point the coroutine will return from its entry function and itsresources are freed.The bdrv_aio_readv() and bdrv_aio_writev() user callback is now invokedfrom a BH. This is necessary since the user callback code does not expect to be executed from a coroutine. This conversion is not completely correct because the safety the synchronous code does not carry over to the coroutine version. Previously, a synchronous code path could assume that it will never be interleaved with another request executing. This is no longer truebecause bdrv_pread() and bdrv_pwrite() cause the coroutine to yield andother requests can be processed during that time. The solution is to carefully introduce checks so that pending requests do not step on each other's toes. That is left for a future patch...The way I thought of doing this is: qcow_aio_write(...) { execute_in_coroutine { co_mutex_lock(&bs->mutex); do_qcow_aio_write(...); // original qcow code co_mutex_release(&bs->mutex);The release has to be executed in the call back.I think it's a bit nicer to not do a mutex, but rather to have a notion of freezing/unfreezing the block queue and instead do:completion() { bdrv_unfreeze(bs); } coroutine { bdrv_freeze(bs); do_qcow_aio_write(completion); }Freeze/unfreeze is useful in a number of other places too (like snapshotting).
Serializing against a global mutex has the advantage that it can be treated as a global lock that is decomposed into fine-grained locks.
For example, we can start the code conversion from an explict async model to a threaded sync model by converting the mutex into a shared/exclusive lock. Operations like read and write take the lock for shared access (and take a fine-grained mutex on the metadata cache entry), while operation like creating a snapshot take the lock for exclusive access. That doesn't work with freeze/thaw.
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |