|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU |
Date: | Tue, 30 Mar 2010 08:54:45 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 03/30/2010 08:28 AM, Avi Kivity wrote:
> block/qcow2-cluster.c: ret = bdrv_read(bs->backing_hd, sector_num, buf, n1);But that offers no advantage to what we have which fails the proof-by-example that threading makes the situation better.It has an advantage, qcow2 is currently synchronous in parts:block/qcow2-cluster.c: ret = bdrv_write(s->hd, (cluster_offset >> 9) + n_start,
The two of these happen in copy_sectors(). copy_sectors() runs from qcow2_alloc_cluster_link_l2() which is called from qcow_aio_write_cb() and preallocate().
block/qcow2.c: bdrv_write(s->hd, (meta.cluster_offset >> 9) + num - 1, buf, 1);
This only happens during creation (for preallocation).
block/qcow2.c: bdrv_write(bs, sector_num, buf, s->cluster_sectors); block/qcow2-cluster.c: ret = bdrv_read(s->hd, coffset >> 9, s->cluster_data, nb_csectors);
These two are only for compressed images.So it looks like we really only have one operation (qcow2_alloc_cluster_link_l2) that blocks. Do we really think that it's sufficiently difficult to make this function asynchronous that it justifies threading the block layer?
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |