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 14:21:00 +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 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




reply via email to

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