virtio-blk: add multiread support
v2 cover virtio-blk: add multiread support
this series adds the long missing multiread support to virtio-blk.
some remarks:
- i introduced rd_merged and wr_merged block accounting stats to blockstats as a generic interface which can be set from any driver that will introduce multirequst merging in the future.
- the knob to disable request merging is not yet there. I would add it to the device properties also as a generic interface to have the same switch on for any driver that might introduce request merging in the future
- there is cleanup and iotest adjustion missing.
RFC v1->v2:
- completed Patch 1 by the example in qmp-commands.hx [Eric]
- used bool for merge in Patch 4 [Max]
- fixed a few typos in the commit msg of Patch 4 [Max]
- do not start merging and directly pass req[0]->qiov in case of num_reqs == 1
- avoid allocating memory for the multireq [Kevin]
- do not import block_int.h and add appropiate iface to block-backend [Kevin]
- removed debug output and added trace event for multireq [Kevin]
- fixed alloc hint for the merge qiov [Kevin]
- currently did not split virtio_submit_multireq into rw code since the redundant code would now be much bigger part than in the original patch.
- added a merge_qiov to VirtioBlockRequest. Abusing the qiov was not possible because it is initialized externally with guest memory [Kevin]
- added a pointer to VirtioBlockRequest to create a linked list of VirtioBlockBlockRequests. This list is used to complete all requests belonging to a multireq [Kevin]
Peter Lieven (4):
block: add accounting for merged requests hw/virtio-blk: add a constant for max number of merged requests
block-backend: expose bs->bl.max_transfer_length
virtio-blk: introduce multiread
block.c | 2 + block/accounting.c | 7 ++ block/block-backend.c | 5 + block/qapi.c | 2 + hmp.c | 6 +- hw/block/dataplane/virtio-blk.c | 10 +- hw/block/virtio-blk.c | 219 ++++++++++++++++++++++----------------- include/block/accounting.h | 3 + include/hw/virtio/virtio-blk.h | 23 ++-- include/sysemu/block-backend.h | 1 + qapi/block-core.json | 9 +- qmp-commands.hx | 22 +++- trace-events | 1 + 13 files changed, 197 insertions(+), 113 deletions(-)
Signature · 1 line
1.7.9.5
RFC PATCH v2 1/4 block: add accounting for merged requests
--- block.c | 2 ++ block/accounting.c | 7 +++++++ block/qapi.c | 2 ++ hmp.c | 6 +++++- include/block/accounting.h | 3 +++ qapi/block-core.json | 9 ++++++++- qmp-commands.hx | 22 ++++++++++++++++++---- 7 files changed, 45 insertions(+), 6 deletions(-)
block.c +2 -0
@@ -4508,6 +4508,8 @@ static int multiwrite_merge(BlockDriverState *bs, BlockRequest *reqs, } } +block_acct_merge_done (&bs->stats,BLOCK_ACCT_WRITE , num_reqs - outidx -1 ); +return outidx +1 ; }
block/accounting.c +7 -0
@@ -52,3 +52,10 @@ void block_acct_highest_sector(BlockAcctStats *stats, int64_t sector_num, stats->wr_highest_sector = sector_num + nb_sectors -1 ; } } + +void block_acct_merge_done (BlockAcctStats *stats,enum BlockAcctType type, +int num_requests) +{ +assert (type <BLOCK_MAX_IOTYPE ); + stats->merged[type] += num_requests; +}
block/qapi.c +2 -0
@@ -316,6 +316,8 @@ static BlockStats *bdrv_query_stats(const BlockDriverState *bs) s->stats->wr_bytes = bs->stats.nr_bytes[BLOCK_ACCT_WRITE ]; s->stats->rd_operations = bs->stats.nr_ops[BLOCK_ACCT_READ ]; s->stats->wr_operations = bs->stats.nr_ops[BLOCK_ACCT_WRITE ]; + s->stats->rd_merged = bs->stats.merged[BLOCK_ACCT_READ ]; + s->stats->wr_merged = bs->stats.merged[BLOCK_ACCT_WRITE ]; s->stats->wr_highest_offset = bs->stats.wr_highest_sector *BDRV_SECTOR_SIZE ; s->stats->flush_operations = bs->stats.nr_ops[BLOCK_ACCT_FLUSH ];
hmp.c +5 -1
@@ -419,6 +419,8 @@ void hmp_info_blockstats(Monitor *mon, const QDict *qdict)" wr_total_time_ns=%" PRId64" rd_total_time_ns=%" PRId64" flush_total_time_ns=%" PRId64 +" rd_merged=%" PRId64 +" wr_merged=%" PRId64"\n" , stats->value->stats->rd_bytes, stats->value->stats->wr_bytes,
@@ -427,7 +429,9 @@ void hmp_info_blockstats(Monitor *mon, const QDict *qdict) stats->value->stats->flush_operations, stats->value->stats->wr_total_time_ns, stats->value->stats->rd_total_time_ns, - stats->value->stats->flush_total_time_ns); + stats->value->stats->flush_total_time_ns, + stats->value->stats->rd_merged, + stats->value->stats->wr_merged); }qapi_free_BlockStatsList (stats_list);
include/block/accounting.h +3 -0
@@ -39,6 +39,7 @@ typedef struct BlockAcctStats {uint64_t nr_bytes[BLOCK_MAX_IOTYPE ];uint64_t nr_ops[BLOCK_MAX_IOTYPE ];uint64_t total_time_ns[BLOCK_MAX_IOTYPE ]; +uint64_t merged[BLOCK_MAX_IOTYPE ];uint64_t wr_highest_sector; } BlockAcctStats;
@@ -53,5 +54,7 @@ void block_acct_start(BlockAcctStats *stats, BlockAcctCookie *cookie,void block_acct_done (BlockAcctStats *stats,BlockAcctCookie *cookie);void block_acct_highest_sector (BlockAcctStats *stats,int64_t sector_num,unsigned int nb_sectors); +void block_acct_merge_done (BlockAcctStats *stats,enum BlockAcctType type, +int num_requests);#endif
qapi/block-core.json +8 -1
@@ -389,13 +389,20 @@ # growable sparse files (like qcow2) that are used on top # of a physical device. # +# @rd_merged: Number of read requests that have been merged into another +# request (Since 2.3). +# +# @wr_merged: Number of write requests that have been merged into another +# request (Since 2.3). +# # Since: 0.14.0 ## { 'type': 'BlockDeviceStats', 'data': {'rd_bytes': 'int', 'wr_bytes': 'int', 'rd_operations': 'int', 'wr_operations': 'int', 'flush_operations': 'int', 'flush_total_time_ns': 'int', 'wr_total_time_ns': 'int', - 'rd_total_time_ns': 'int', 'wr_highest_offset': 'int' } } + 'rd_total_time_ns': 'int', 'wr_highest_offset': 'int', + 'rd_merged': 'int', 'wr_merged': 'int' } } ## # @BlockStats:
qmp-commands.hx +18 -4
@@ -2261,6 +2261,10 @@ Each json-object contain the following: - "flush_total_time_ns": total time spend on cache flushes in nano-seconds (json-int) - "wr_highest_offset": Highest offset of a sector written since the BlockDriverState has been opened (json-int) + - "rd_merged": number of read requests that have been merged into + another request (json-int) + - "wr_merged": number of write requests that have been merged into + another request (json-int) - "parent": Contains recursively the statistics of the underlying protocol (e.g. the host file for a qcow2 image). If there is no underlying protocol, this field is omitted
@@ -2284,6 +2288,8 @@ Example: "rd_total_times_ns":3465673657 "flush_total_times_ns":49653 "flush_operations":61, + "rd_merged":0, + "wr_merged":0 } }, "stats":{
@@ -2295,7 +2301,9 @@ Example: "flush_operations":51, "wr_total_times_ns":313253456 "rd_total_times_ns":3465673657 - "flush_total_times_ns":49653 + "flush_total_times_ns":49653, + "rd_merged":0, + "wr_merged":0 } }, {
@@ -2309,7 +2317,9 @@ Example: "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 - "flush_total_times_ns":0 + "flush_total_times_ns":0, + "rd_merged":0, + "wr_merged":0 } }, {
@@ -2323,7 +2333,9 @@ Example: "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 - "flush_total_times_ns":0 + "flush_total_times_ns":0, + "rd_merged":0, + "wr_merged":0 } }, {
@@ -2337,7 +2349,9 @@ Example: "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 - "flush_total_times_ns":0 + "flush_total_times_ns":0, + "rd_merged":0, + "wr_merged":0 } } ]
Signature · 1 line
1.7.9.5
Re: [Qemu-devel] [RFC PATCH V2 1/4] block: add accounting for merged requests
Quoted 12 lines · Peter Lieven
Signed-off-by Peter Lieven <[email protected]>--- block.c | 2 ++ block/accounting.c | 7 +++++++ block/qapi.c | 2 ++ hmp.c | 6 +++++- include/block/accounting.h | 3 +++ qapi/block-core.json | 9 ++++++++- qmp-commands.hx | 22 ++++++++++++++++++---- 7 files changed, 45 insertions(+), 6 deletions(-)
qmp-commands.hx Example: · line 2292
Quoted 5 lines
qmp-commands.hx +2
-0@@ -2284,6 +2288,8 @@ Example: "rd_total_times_ns":3465673657 "flush_total_times_ns":49653 "flush_operations":61, + "rd_merged":0, + "wr_merged":0
Oh my - we previously had invalid JSON in our example. Yay that this fixes it :)
Signature · 2 lines
Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [RFC PATCH V2 1/4] block: add accounting for merged requests
Quoted 11 lines · Eric Blake
Quoted 10 lines · Peter Lieven
Signed-off-by Peter Lieven <[email protected]>--- block.c | 2 ++ block/accounting.c | 7 +++++++ block/qapi.c | 2 ++ hmp.c | 6 +++++- include/block/accounting.h | 3 +++ qapi/block-core.json | 9 ++++++++- qmp-commands.hx | 22 ++++++++++++++++++---- 7 files changed, 45 insertions(+), 6 deletions(-)
Quoted 8 lines
qmp-commands.hx Example: · line 2292
Quoted 6 lines
qmp-commands.hx +2
-0@@ -2284,6 +2288,8 @@ Example: "rd_total_times_ns":3465673657 "flush_total_times_ns":49653 "flush_operations":61, + "rd_merged":0, + "wr_merged":0Oh my - we previously had invalid JSON in our example. Yay that this fixes it :)
There is actually more invalid JSON, but I would fix that in a separate patch apart from this series.
Peter
RFC PATCH v2 2/4 hw/virtio-blk: add a constant for max number of merged requests
In reply to Peter LievenAs it was not obvious (at least for me) where the 32 comes from; add a constant for it.
--- hw/block/virtio-blk.c | 2 +- include/hw/virtio/virtio-blk.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-)
hw/block/virtio-blk.c +1 -1
@@ -326,7 +326,7 @@ static void virtio_blk_handle_write(VirtIOBlockReq *req, MultiReqBuffer *mrb)block_acct_start (blk_get_stats (req->dev->blk), &req->acct, req->qiov.size,BLOCK_ACCT_WRITE ); -if (mrb->num_writes ==32 ) { +if (mrb->num_writes ==VIRTIO_BLK_MAX_MERGE_REQS ) {virtio_submit_multiwrite (req->dev->blk, mrb); }
include/hw/virtio/virtio-blk.h +3 -1
@@ -134,8 +134,10 @@ typedef struct VirtIOBlock {struct VirtIOBlockDataPlane *dataplane; } VirtIOBlock; +#define VIRTIO_BLK_MAX_MERGE_REQS 32 +typedef struct MultiReqBuffer { -BlockRequest blkreq[32 ]; +BlockRequest blkreq[VIRTIO_BLK_MAX_MERGE_REQS ];unsigned int num_writes; }MultiReqBuffer ;
Signature · 1 line
1.7.9.5
Re: [Qemu-devel] [RFC PATCH V2 2/4] hw/virtio-blk: add a constant for max number of merged requests
Quoted 8 lines · Peter Lieven
As it was not obvious (at least for me) where the 32 comes from; add a constant for it.
Signed-off-by Peter Lieven <[email protected]>--- hw/block/virtio-blk.c | 2 +- include/hw/virtio/virtio-blk.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-)
Signature · 2 lines
Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
RFC PATCH v2 3/4 block-backend: expose bs->bl.max_transfer_length
In reply to Peter Lieven--- block/block-backend.c | 5 +++++ include/sysemu/block-backend.h | 1 + 2 files changed, 6 insertions(+)
block/block-backend.c +5 -0
@@ -569,6 +569,11 @@ int blk_get_flags(BlockBackend *blk)return bdrv_get_flags (blk->bs); } +int blk_get_max_transfer_length (BlockBackend *blk) +{ +return blk->bs->bl.max_transfer_length; +} +void blk_set_guest_block_size (BlockBackend *blk,int align) {bdrv_set_guest_block_size (blk->bs, align);
include/sysemu/block-backend.h +1 -0
@@ -124,6 +124,7 @@ int blk_is_inserted(BlockBackend *blk);void blk_lock_medium (BlockBackend *blk,bool locked);void blk_eject (BlockBackend *blk,bool eject_flag);int blk_get_flags (BlockBackend *blk); +int blk_get_max_transfer_length (BlockBackend *blk);void blk_set_guest_block_size (BlockBackend *blk,int align);void *blk_blockalign (BlockBackend *blk,size_t size);bool blk_op_is_blocked (BlockBackend *blk,BlockOpType op,Error **errp);
Signature · 1 line
1.7.9.5
RFC PATCH v2 4/4 virtio-blk: introduce multiread
In reply to Peter Lieventhis patch finally introduce multiread support to virtio-blk while multiwrite support was there for a long time read support was missing.
To achieve this the patch does serveral things which might need futher explaination:
- the whole merge and multireq logic is moved from block.c into virtio-blk. This is move is a preparation for directly creating a coroutine out of virtio-blk.
- requests are only merged if they are strictly sequential and no longer sorted. This simplification decreases overhead and reduces latency. It will also merge some requests which were unmergable before.
The old algorithm took up to 32 requests sorted them and tried to merge them. The outcome was anything between 1 and 32 requests. In case of 32 requests there were 31 requests unnecessarily delayed.
On the other hand lets imagine e.g. 16 unmergeable requests followed by 32 mergable requests. The latter 32 requests would have been split into two 16 byte requests.
Last the simplified logic allows for a fast path if we have only a single request in the multirequest. In this case the request is sent as ordinary request without mulltireq callbacks.
As a first benchmark I installed Ubuntu 14.04.1 on a ramdisk. The number of merged requests is in the same order while the latency is slightly decreased. One should not stick too much to the numbers because the number of wr_requests are highly fluctuant. I hope the numbers show that this patch is at least not causing too big harm:
Cmdline:
qemu-system-x86_64 -m 1024 -smp 2 -enable-kvm -cdrom ubuntu-14.04.1-server-amd64.iso \
-drive if=virtio,file=/tmp/ubuntu.raw -monitor stdio
Before:
virtio0: rd_bytes=150979072 wr_bytes=2591138816 rd_operations=18475 wr_operations=69216
flush_operations=15343 wr_total_time_ns=26969283701 rd_total_time_ns=1018449432 flush_total_time_ns=562596819 rd_merged=0 wr_merged=10453
After:
virtio0: rd_bytes=148112896 wr_bytes=2845834240 rd_operations=17535 wr_operations=72197
flush_operations=15760 wr_total_time_ns=26104971623 rd_total_time_ns=1012926283 flush_total_time_ns=564414752 rd_merged=517 wr_merged=9859
Some first numbers of improved read performance while booting:
The Ubuntu 14.04.1 vServer from above:
virtio0: rd_bytes=86158336 wr_bytes=688128 rd_operations=5851 wr_operations=70
flush_operations=4 wr_total_time_ns=10886705 rd_total_time_ns=416688595 flush_total_time_ns=288776 rd_merged=1297 wr_merged=2
Windows 2012R2:
virtio0: rd_bytes=176559104 wr_bytes=61859840 rd_operations=7200 wr_operations=360
flush_operations=68 wr_total_time_ns=34344992718 rd_total_time_ns=134386844669 flush_total_time_ns=18115517 rd_merged=641 wr_merged=216
--- hw/block/dataplane/virtio-blk.c | 10 +- hw/block/virtio-blk.c | 219 ++++++++++++++++++++++----------------- include/hw/virtio/virtio-blk.h | 25 +++-- trace-events | 1 + 4 files changed, 146 insertions(+), 109 deletions(-)
hw/block/dataplane/virtio-blk.c +5 -5
@@ -96,9 +96,8 @@ static void handle_notify(EventNotifier *e)event_notifier_test_and_clear (&s->host_notifier);blk_io_plug (s->conf->conf.blk);for (;;) { -MultiReqBuffer mrb = { - .num_writes =0 , - }; +MultiReqBuffer mrb_rd = {}; +MultiReqBuffer mrb_wr = {.is_write =1 };int ret;/* Disable guest->host notifies to avoid unnecessary vmexits */
@@ -117,10 +116,11 @@ static void handle_notify(EventNotifier *e) req->elem.in_num, req->elem.index); -virtio_blk_handle_request (req, &mrb); +virtio_blk_handle_request (req, &mrb_wr, &mrb_rd); } -virtio_submit_multiwrite (s->conf->conf.blk, &mrb); +virtio_submit_multireq (s->conf->conf.blk, &mrb_wr); +virtio_submit_multireq (s->conf->conf.blk, &mrb_rd);if (likely (ret == -EAGAIN )) {/* vring emptied */ /* Re-enable guest->host notifies and stop processing the vring.
hw/block/virtio-blk.c +124 -95
303 lines not on this page · raw message
include/hw/virtio/virtio-blk.h +16 -9
@@ -134,13 +134,6 @@ typedef struct VirtIOBlock {struct VirtIOBlockDataPlane *dataplane; } VirtIOBlock; -#define VIRTIO_BLK_MAX_MERGE_REQS 32 - -typedef struct MultiReqBuffer { -BlockRequest blkreq[VIRTIO_BLK_MAX_MERGE_REQS ]; -unsigned int num_writes; -}MultiReqBuffer ; - typedef struct VirtIOBlockReq { VirtIOBlock *dev; VirtQueueElement elem;
@@ -149,8 +142,21 @@ typedef struct VirtIOBlockReq {QEMUIOVector qiov;struct VirtIOBlockReq *next;BlockAcctCookie acct; +QEMUIOVector mr_qiov; +struct VirtIOBlockReq *mr_next; } VirtIOBlockReq; +#define MAX_MERGE_REQS 32 + +typedef struct MultiReqBuffer { +VirtIOBlockReq *reqs[MAX_MERGE_REQS ]; +unsigned int num_reqs; +bool is_write; +int niov; +int64_t sector_num; +int nb_sectors; +}MultiReqBuffer ; +VirtIOBlockReq *virtio_blk_alloc_request (VirtIOBlock *s);void virtio_blk_free_request (VirtIOBlockReq *req);
@@ -158,8 +164,9 @@ void virtio_blk_free_request(VirtIOBlockReq *req);int virtio_blk_handle_scsi_req (VirtIOBlock *blk,VirtQueueElement *elem); -void virtio_blk_handle_request (VirtIOBlockReq *req,MultiReqBuffer *mrb); +void virtio_blk_handle_request (VirtIOBlockReq *req,MultiReqBuffer *mrb_wr, +MultiReqBuffer *mrb_rd); -void virtio_submit_multiwrite (BlockBackend *blk,MultiReqBuffer *mrb); +void virtio_submit_multireq (BlockBackend *blk,MultiReqBuffer *mrb);#endif
trace-events +1 -0
@@ -116,6 +116,7 @@ virtio_blk_req_complete(void *req, int status) "req %p status %d" virtio_blk_rw_complete(void *req, int ret) "req %p ret %d" virtio_blk_handle_write(void *req, uint64_t sector, size_t nsectors) "req %p sector %"PRIu64" nsectors %zu" virtio_blk_handle_read(void *req, uint64_t sector, size_t nsectors) "req %p sector %"PRIu64" nsectors %zu" +virtio_blk_submit_multireq(void *mrb, int num_reqs, uint64_t sector, size_t nsectors, bool is_write) "mrb %p num_reqs %d sector %"PRIu64" nsectors %zu is_write %d" # hw/block/dataplane/virtio-blk.c virtio_blk_data_plane_start(void *s) "dataplane %p"
Signature · 1 line
1.7.9.5
Re: [Qemu-devel] [RFC PATCH V2 4/4] virtio-blk: introduce multiread
Quoted 1 line · Peter Lieven
this patch finally introduce multiread support to virtio-blk while
s/introduce/introduces/
s/virtio-blk while/virtio-blk. While/
Quoted 1 line
multiwrite support was there for a long time read support was missing.
s/time/time,/
Quoted 2 lines
To achieve this the patch does serveral things which might need futher
s/serveral/several/
s/futher/further/
Quoted 1 line
explaination:
s/explaination/explanation/
Quoted 4 lines
- the whole merge and multireq logic is moved from
block.cinto virtio-blk. This is move is a preparation for directly creating a coroutine out of virtio-blk.
Can this move be done as a separate prerequisite patch? Mixing code motion and new features in the same patch is harder to review.
Quoted 2 lines
- requests are only merged if they are strictly sequential and no
s/sequential/sequential,/
Quoted 4 lines
longer sorted. This simplification decreases overhead and reduces latency. It will also merge some requests which were unmergable before.
The old algorithm took up to 32 requests sorted them and tried to merge
s/requests/requests,/
Quoted 4 lines
them. The outcome was anything between 1 and 32 requests. In case of 32 requests there were 31 requests unnecessarily delayed.
On the other hand lets imagine e.g. 16 unmergeable requests followed
s/lets/let's/
Quoted 6 lines
by 32 mergable requests. The latter 32 requests would have been split into two 16 byte requests.
Last the simplified logic allows for a fast path if we have only a single request in the multirequest. In this case the request is sent as ordinary request without mulltireq callbacks.
s/mulltireq/multireq/
Quoted 7 lines
As a first benchmark I installed Ubuntu 14.04.1 on a ramdisk. The number of merged requests is in the same order while the latency is slightly decreased. One should not stick too much to the numbers because the number of
wr_requestsare highly fluctuant. I hope the numbers show that this patch is at least not causing too big harm:
I'll leave the actual patch review to developers more knowledgeable about block behavior.
Signature · 2 lines
Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [RFC PATCH V2 4/4] virtio-blk: introduce multiread
Quoted 12 lines · Eric Blake
Quoted 1 line · Peter Lieven
this patch finally introduce multiread support to virtio-blk while
s/introduce/introduces/
s/virtio-blk while/virtio-blk. While/Quoted 1 line
multiwrite support was there for a long time read support was missing.
s/time/time,/
Quoted 1 line
To achieve this the patch does serveral things which might need futher
s/serveral/several/
s/futher/further/
Quoted 8 lines
Quoted 1 line
explaination:
s/explaination/explanation/
Quoted 3 lines
- the whole merge and multireq logic is moved from
block.cinto virtio-blk. This is move is a preparation for directly creating a coroutine out of virtio-blk.Can this move be done as a separate prerequisite patch? Mixing code motion and new features in the same patch is harder to review.
The issue is that the code is not movable. I could artifically use the new code in a new patch only for write requests and add another patch to add read merging. But I doubt that it would make it easier to review but even harder.
Peter