On 01/27/2011 12:09 PM, Stefan Hajnoczi wrote:
>
>
> 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);
> }
> }
I think this approach makes sense as the next step towards a
fine-grained strategy.
Remember that qcow2 is not just:
qcow2_aio_write(...)
{
sync_io(...);
aio_write(...);
complete_request(...); /* in callback */
}
It is actually:
qcow2_aio_write(...)
{
sync_io(...);
aio_write(...);
more_sync_io(...); /* in callback */
complete_request(...);
}
We need to make sure the synchronous I/O after aio write completion is
also guarded.
Correct. Every entry point into qcow2 needs to be wrapped.
Maybe the best way forward is to implement it in the block layer. While
that makes additional hacking harder, it emphasises the fact that qcow2
logic need not be changed in any way in order to remove vcpu blocking
without compromising concurrency.
The block layer could examine BlockDriver::not_really_async, and if set,
instead of calling BlockDriver::bdrv_aio_writev, it can call a wrapper
which schedules a coroutine and returns a fake AIOCB. The wrapper would
also wrap the completion with a wrapper, so that it too would execute
under a coroutine. The mutex would be managed by the wrapper, and qcow2
would be completely unchanged except for setting not_really_async.
--
error compiling committee.c: too many arguments to function
