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:
1. Rename X into do_X. If X is called directly from within qcow2,
change the call to do_x. Create a new X which simply calls do_X().
This change is purely textual and doesn't affect runtime at all.
2. Change X to
X()
{
create a coroutine
pack arguments to X in a structure
schedule the coroutine to execute a new function call_X with the
structure as argument
wait for the coroutine to complete
unpack the result (if any)
dispose of the coroutine
return the result
}
call_X()
{
unpack arguments
co_mutex_lock(&bs->mutex)
result = do_X()
co_mutex_unlock(&bs->mutex)
pack result
}
(in the case of aio_X callbacks, we return a fake AIOCB:
aio_X()
{
allocate AIOCB
allocate coroutine
pack arguments to X, and fake AIOCB in a structure
schedule the coroutine to execute call_X with the structure as
argument
return fake AIOCB
}
call_aio_X()
{
unpack arguments
co_mutex_lock(&bs->mutex)
do_X()
co_mutex_unlock(&bs->mutex)
}
and change the completion to complete the fake AIOCB
)
The result of this transformation is:
- if X1 executed without blocking, it still executes without blocking,
except for the case below
- if X2 blocked, it will serialize any X1 which doesn't, but it will no
longer block the vcpu thread
We could do this transformation in the block layer, as it doesn't
involve qcow2 at all. I don't think that's a good idea, though, as
qcow2 would be the only beneficiary and it would be harder to further
evolve qcow2.
--
error compiling committee.c: too many arguments to function
