On 01/27/2011 01:27 PM, Kevin Wolf wrote:
Am 27.01.2011 11:41, schrieb Avi Kivity:
> On 01/27/2011 12:34 PM, Kevin Wolf wrote:
>> Am 27.01.2011 10:49, schrieb Avi Kivity:
>>> On 01/27/2011 11:27 AM, Kevin Wolf wrote:
>>>> Well, but in the case of qcow2, you don't want to have a big mutex
>>>> around everything. We perfectly know which parts are asynchronous and
>>>> which are synchronous, so we'd want to do it finer grained from the
>>>> beginning.
>>>
>>> Yes we do. And the way I proposed it, the new mutex does not introduce
>>> any new serialization.
>>>
>>> To repeat, for every qcow2 callback or completion X (not qcow2 read or
>>> write operation), we transform it in the following manner:
>>> [...]
>>
>> This works fine for code that is completely synchronous today (and you
>> can't serialize it more than it already is anyway).
>>
>> It doesn't work for qemu_aio_readv/writev because these use AIO for
>> reading/writing the data. So you definitely need to rewrite that part,
>> or the AIO callback will cause the code to run outside its coroutine.
>
> The callbacks need to be wrapped in the same way. Schedule a coroutine
> to run the true callback.
Okay, I see what you're proposing. You could schedule a new coroutine
for callbacks indeed.
But I think it's actually easier to convert the bdrv_aio_readv into a
bdrv_co_readv (and by that removing the callback) and just make sure
that you don't hold the mutex during this call - basically what Stefan's
code does, just with mutexes instead of a request queue.
My approach was for someone who isn't too familiar with qcow2 - a
mindless conversion. A more integrated approach is better, since it
will lead to tighter code, and if Stefan or you are able to do it
without impacting concurrency, I'm all for it.
>> And during this rewrite you'll want to pay attention that you don't hold
>> the mutex for the bdrv_co_readv that was an AIO request before, or
>> you'll introduce additional serialization.
>
> I don't follow. Please elaborate.
We were thinking of different approaches. I hope it's clearer now.
I think so.
--
error compiling committee.c: too many arguments to function
