qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 11/12] qcow2: Convert qcow2 to use coroutin


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC][PATCH 11/12] qcow2: Convert qcow2 to use coroutines for async I/O
Date: Thu, 27 Jan 2011 12:46:58 +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/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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]