On 01/26/2011 07:12 PM, Anthony Liguori wrote:
What do you actually save? The longjmp() to the coroutine code,
linking in to the mutex wait queue, and another switch back to the
main coroutine? Given that we don't expect to block often, it seems
hardly a cost worth optimizing.
It's a
Am 26.01.2011 18:12, schrieb Anthony Liguori:
On 01/26/2011 10:38 AM, Avi Kivity wrote:
On 01/26/2011 06:28 PM, Anthony Liguori wrote:
On 01/26/2011 10:13 AM, Avi Kivity wrote:
Serializing against a global mutex has the advantage that it can be
treated as a global lock that is decomposed
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
On Wed, Jan 26, 2011 at 05:40:27PM +0200, Avi Kivity wrote:
On 01/22/2011 11:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
transparently work when called from a
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
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
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
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
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
On 01/22/2011 11:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
transparently work when called from a coroutine, so all the synchronous
code just works.
The explicitly
Am 26.01.2011 16:40, schrieb Avi Kivity:
On 01/22/2011 11:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
transparently work when called from a coroutine, so all the
On 01/26/2011 09:50 AM, Kevin Wolf wrote:
Am 26.01.2011 16:40, schrieb Avi Kivity:
On 01/22/2011 11:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
On 01/26/2011 05:50 PM, Kevin Wolf wrote:
In the other thread you mentioned that you have written some code
independently. Do you have it in some public git repository?
I've written it mostly in my mind... IIRC I have the basic coroutine
equivalents (in my series they are simply threads,
On 01/26/2011 06:08 PM, Anthony Liguori wrote:
On 01/26/2011 09:50 AM, Kevin Wolf wrote:
Am 26.01.2011 16:40, schrieb Avi Kivity:
On 01/22/2011 11:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of
qcow2
is synchronous. The synchronous I/O
On 01/26/2011 10:13 AM, Avi Kivity wrote:
Serializing against a global mutex has the advantage that it can be
treated as a global lock that is decomposed into fine-grained locks.
For example, we can start the code conversion from an explict async
model to a threaded sync model by converting
On 01/26/2011 06:28 PM, Anthony Liguori wrote:
On 01/26/2011 10:13 AM, Avi Kivity wrote:
Serializing against a global mutex has the advantage that it can be
treated as a global lock that is decomposed into fine-grained locks.
For example, we can start the code conversion from an explict async
On 01/26/2011 10:38 AM, Avi Kivity wrote:
On 01/26/2011 06:28 PM, Anthony Liguori wrote:
On 01/26/2011 10:13 AM, Avi Kivity wrote:
Serializing against a global mutex has the advantage that it can be
treated as a global lock that is decomposed into fine-grained locks.
For example, we can
On Sun, Jan 23, 2011 at 11:40 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 01/22/2011 03:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
transparently work when
On 01/22/2011 03:29 AM, Stefan Hajnoczi wrote:
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
transparently work when called from a coroutine, so all the synchronous
code just works.
The explicitly
Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous. The synchronous I/O functions likes bdrv_pread() now
transparently work when called from a coroutine, so all the synchronous
code just works.
The explicitly asynchronous code is adjusted to repeatedly call
20 matches
Mail list logo
