| Message ID | 20201026171815.13233-3-vsementsov@virtuozzo.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | backup performance: block_status + async | expand |
On 26.10.20 18:17, Vladimir Sementsov-Ogievskiy wrote: > Experiments show, that copy_range is not always making things faster. > So, to make experimentation simpler, let's add a parameter. Some more > perf parameters will be added soon, so here is a new struct. > > For now, add new backup qmp parameter with x- prefix for the following > reasons: > > - We are going to add more performance parameters, some will be > related to the whole block-copy process, some only to background > copying in backup (ignored for copy-before-write operations). > - On the other hand, we are going to use block-copy interface in other > block jobs, which will need performance options as well.. And it > should be the same structure or at least somehow related. > > So, there are too much unclean things about how the interface and now > we need the new options mostly for testing. Let's keep them > experimental for a while. > > In do_backup_common() new x-perf parameter handled in a way to > make further options addition simpler. > > We add use-copy-range with default=true, and we'll change the default > in further patch, after moving backup to use block-copy. > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > qapi/block-core.json | 17 ++++++++++++++++- > block/backup-top.h | 1 + > include/block/block-copy.h | 2 +- > include/block/block_int.h | 3 +++ > block/backup-top.c | 4 +++- > block/backup.c | 6 +++++- > block/block-copy.c | 4 ++-- > block/replication.c | 2 ++ > blockdev.c | 8 ++++++++ > 9 files changed, 41 insertions(+), 6 deletions(-) Reviewed-by: Max Reitz <mreitz@redhat.com>
On 10/26/20 12:17 PM, Vladimir Sementsov-Ogievskiy wrote: > Experiments show, that copy_range is not always making things faster. > So, to make experimentation simpler, let's add a parameter. Some more > perf parameters will be added soon, so here is a new struct. > > For now, add new backup qmp parameter with x- prefix for the following > reasons: > > - We are going to add more performance parameters, some will be > related to the whole block-copy process, some only to background > copying in backup (ignored for copy-before-write operations). > - On the other hand, we are going to use block-copy interface in other > block jobs, which will need performance options as well.. And it > should be the same structure or at least somehow related. > > So, there are too much unclean things about how the interface and now > we need the new options mostly for testing. Let's keep them > experimental for a while. > > In do_backup_common() new x-perf parameter handled in a way to > make further options addition simpler. > > We add use-copy-range with default=true, and we'll change the default > in further patch, after moving backup to use block-copy. > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > +++ b/qapi/block-core.json > @@ -1370,6 +1370,19 @@ > { 'struct': 'BlockdevSnapshot', > 'data': { 'node': 'str', 'overlay': 'str' } } > > +## > +# @BackupPerf: > +# > +# Optional parameters for backup. These parameters don't affect > +# functionality, but may significantly affect performance. > +# > +# @use-copy-range: Use copy offloading. Default true. > +# > +# Since: 5.2 We've missed 5.2; this will need to be updated to 6.0 > +## > +{ 'struct': 'BackupPerf', > + 'data': { '*use-copy-range': 'bool' }} > + > ## > # @BackupCommon: > # > @@ -1425,6 +1438,8 @@ > # above node specified by @drive. If this option is not given, > # a node name is autogenerated. (Since: 4.2) > # > +# @x-perf: Performance options. (Since 5.2) and here
19.01.2021 23:21, Eric Blake wrote: > On 10/26/20 12:17 PM, Vladimir Sementsov-Ogievskiy wrote: >> Experiments show, that copy_range is not always making things faster. >> So, to make experimentation simpler, let's add a parameter. Some more >> perf parameters will be added soon, so here is a new struct. >> >> For now, add new backup qmp parameter with x- prefix for the following >> reasons: >> >> - We are going to add more performance parameters, some will be >> related to the whole block-copy process, some only to background >> copying in backup (ignored for copy-before-write operations). >> - On the other hand, we are going to use block-copy interface in other >> block jobs, which will need performance options as well.. And it >> should be the same structure or at least somehow related. >> >> So, there are too much unclean things about how the interface and now >> we need the new options mostly for testing. Let's keep them >> experimental for a while. >> >> In do_backup_common() new x-perf parameter handled in a way to >> make further options addition simpler. >> >> We add use-copy-range with default=true, and we'll change the default >> in further patch, after moving backup to use block-copy. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> >> --- > >> +++ b/qapi/block-core.json >> @@ -1370,6 +1370,19 @@ >> { 'struct': 'BlockdevSnapshot', >> 'data': { 'node': 'str', 'overlay': 'str' } } >> >> +## >> +# @BackupPerf: >> +# >> +# Optional parameters for backup. These parameters don't affect >> +# functionality, but may significantly affect performance. >> +# >> +# @use-copy-range: Use copy offloading. Default true. >> +# >> +# Since: 5.2 > > We've missed 5.2; this will need to be updated to 6.0 > >> +## >> +{ 'struct': 'BackupPerf', >> + 'data': { '*use-copy-range': 'bool' }} >> + >> ## >> # @BackupCommon: >> # >> @@ -1425,6 +1438,8 @@ >> # above node specified by @drive. If this option is not given, >> # a node name is autogenerated. (Since: 4.2) >> # >> +# @x-perf: Performance options. (Since 5.2) > > and here > I wanted to say that it's fixed in v4 (which is already in Max's tree), but... It's not fixed. Max, could you touch this up?
On 20.01.21 07:09, Vladimir Sementsov-Ogievskiy wrote: > 19.01.2021 23:21, Eric Blake wrote: >> On 10/26/20 12:17 PM, Vladimir Sementsov-Ogievskiy wrote: >>> Experiments show, that copy_range is not always making things faster. >>> So, to make experimentation simpler, let's add a parameter. Some more >>> perf parameters will be added soon, so here is a new struct. >>> >>> For now, add new backup qmp parameter with x- prefix for the following >>> reasons: >>> >>> - We are going to add more performance parameters, some will be >>> related to the whole block-copy process, some only to background >>> copying in backup (ignored for copy-before-write operations). >>> - On the other hand, we are going to use block-copy interface in other >>> block jobs, which will need performance options as well.. And it >>> should be the same structure or at least somehow related. >>> >>> So, there are too much unclean things about how the interface and now >>> we need the new options mostly for testing. Let's keep them >>> experimental for a while. >>> >>> In do_backup_common() new x-perf parameter handled in a way to >>> make further options addition simpler. >>> >>> We add use-copy-range with default=true, and we'll change the default >>> in further patch, after moving backup to use block-copy. >>> >>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> >>> --- >> >>> +++ b/qapi/block-core.json >>> @@ -1370,6 +1370,19 @@ >>> { 'struct': 'BlockdevSnapshot', >>> 'data': { 'node': 'str', 'overlay': 'str' } } >>> +## >>> +# @BackupPerf: >>> +# >>> +# Optional parameters for backup. These parameters don't affect >>> +# functionality, but may significantly affect performance. >>> +# >>> +# @use-copy-range: Use copy offloading. Default true. >>> +# >>> +# Since: 5.2 >> >> We've missed 5.2; this will need to be updated to 6.0 >> >>> +## >>> +{ 'struct': 'BackupPerf', >>> + 'data': { '*use-copy-range': 'bool' }} >>> + >>> ## >>> # @BackupCommon: >>> # >>> @@ -1425,6 +1438,8 @@ >>> # above node specified by @drive. If this option >>> is not given, >>> # a node name is autogenerated. (Since: 4.2) >>> # >>> +# @x-perf: Performance options. (Since 5.2) >> >> and here >> > > I wanted to say that it's fixed in v4 (which is already in Max's tree), > but... It's not fixed. Max, could you touch this up? Sure. Max
diff --git a/qapi/block-core.json b/qapi/block-core.json index e74669159c..71e6faa15c 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -1370,6 +1370,19 @@ { 'struct': 'BlockdevSnapshot', 'data': { 'node': 'str', 'overlay': 'str' } } +## +# @BackupPerf: +# +# Optional parameters for backup. These parameters don't affect +# functionality, but may significantly affect performance. +# +# @use-copy-range: Use copy offloading. Default true. +# +# Since: 5.2 +## +{ 'struct': 'BackupPerf', + 'data': { '*use-copy-range': 'bool' }} + ## # @BackupCommon: # @@ -1425,6 +1438,8 @@ # above node specified by @drive. If this option is not given, # a node name is autogenerated. (Since: 4.2) # +# @x-perf: Performance options. (Since 5.2) +# # Note: @on-source-error and @on-target-error only affect background # I/O. If an error occurs during a guest write request, the device's # rerror/werror actions will be used. @@ -1439,7 +1454,7 @@ '*on-source-error': 'BlockdevOnError', '*on-target-error': 'BlockdevOnError', '*auto-finalize': 'bool', '*auto-dismiss': 'bool', - '*filter-node-name': 'str' } } + '*filter-node-name': 'str', '*x-perf': 'BackupPerf' } } ## # @DriveBackup: diff --git a/block/backup-top.h b/block/backup-top.h index e5cabfa197..b28b0031c4 100644 --- a/block/backup-top.h +++ b/block/backup-top.h @@ -33,6 +33,7 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source, BlockDriverState *target, const char *filter_node_name, uint64_t cluster_size, + BackupPerf *perf, BdrvRequestFlags write_flags, BlockCopyState **bcs, Error **errp); diff --git a/include/block/block-copy.h b/include/block/block-copy.h index aac85e1488..6397505f30 100644 --- a/include/block/block-copy.h +++ b/include/block/block-copy.h @@ -22,7 +22,7 @@ typedef void (*ProgressBytesCallbackFunc)(int64_t bytes, void *opaque); typedef struct BlockCopyState BlockCopyState; BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target, - int64_t cluster_size, + int64_t cluster_size, bool use_copy_range, BdrvRequestFlags write_flags, Error **errp); diff --git a/include/block/block_int.h b/include/block/block_int.h index 887b0668d8..dc1ed349df 100644 --- a/include/block/block_int.h +++ b/include/block/block_int.h @@ -1248,6 +1248,8 @@ void mirror_start(const char *job_id, BlockDriverState *bs, * @sync_mode: What parts of the disk image should be copied to the destination. * @sync_bitmap: The dirty bitmap if sync_mode is 'bitmap' or 'incremental' * @bitmap_mode: The bitmap synchronization policy to use. + * @perf: Performance options. All actual fields assumed to be present, + * all ".has_*" fields are ignored. * @on_source_error: The action to take upon error reading from the source. * @on_target_error: The action to take upon error writing to the target. * @creation_flags: Flags that control the behavior of the Job lifetime. @@ -1266,6 +1268,7 @@ BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs, BitmapSyncMode bitmap_mode, bool compress, const char *filter_node_name, + BackupPerf *perf, BlockdevOnError on_source_error, BlockdevOnError on_target_error, int creation_flags, diff --git a/block/backup-top.c b/block/backup-top.c index fe6883cc97..789acf6965 100644 --- a/block/backup-top.c +++ b/block/backup-top.c @@ -186,6 +186,7 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source, BlockDriverState *target, const char *filter_node_name, uint64_t cluster_size, + BackupPerf *perf, BdrvRequestFlags write_flags, BlockCopyState **bcs, Error **errp) @@ -244,7 +245,8 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source, state->cluster_size = cluster_size; state->bcs = block_copy_state_new(top->backing, state->target, - cluster_size, write_flags, &local_err); + cluster_size, perf->use_copy_range, + write_flags, &local_err); if (local_err) { error_prepend(&local_err, "Cannot create block-copy-state: "); goto fail; diff --git a/block/backup.c b/block/backup.c index 9afa0bf3b4..4b07e9115d 100644 --- a/block/backup.c +++ b/block/backup.c @@ -46,6 +46,7 @@ typedef struct BackupBlockJob { uint64_t len; uint64_t bytes_read; int64_t cluster_size; + BackupPerf perf; BlockCopyState *bcs; } BackupBlockJob; @@ -335,6 +336,7 @@ BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs, BitmapSyncMode bitmap_mode, bool compress, const char *filter_node_name, + BackupPerf *perf, BlockdevOnError on_source_error, BlockdevOnError on_target_error, int creation_flags, @@ -441,7 +443,8 @@ BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs, (compress ? BDRV_REQ_WRITE_COMPRESSED : 0), backup_top = bdrv_backup_top_append(bs, target, filter_node_name, - cluster_size, write_flags, &bcs, errp); + cluster_size, perf, + write_flags, &bcs, errp); if (!backup_top) { goto error; } @@ -464,6 +467,7 @@ BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs, job->bcs = bcs; job->cluster_size = cluster_size; job->len = len; + job->perf = *perf; block_copy_set_progress_callback(bcs, backup_progress_bytes_callback, job); block_copy_set_progress_meter(bcs, &job->common.job.progress); diff --git a/block/block-copy.c b/block/block-copy.c index cd9bc47c8f..63398a171c 100644 --- a/block/block-copy.c +++ b/block/block-copy.c @@ -218,7 +218,7 @@ static uint32_t block_copy_max_transfer(BdrvChild *source, BdrvChild *target) } BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target, - int64_t cluster_size, + int64_t cluster_size, bool use_copy_range, BdrvRequestFlags write_flags, Error **errp) { BlockCopyState *s; @@ -260,7 +260,7 @@ BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target, * We enable copy-range, but keep small copy_size, until first * successful copy_range (look at block_copy_do_copy). */ - s->use_copy_range = true; + s->use_copy_range = use_copy_range; s->copy_size = MAX(s->cluster_size, BLOCK_COPY_MAX_BUFFER); } diff --git a/block/replication.c b/block/replication.c index 0c70215784..22ffc811ee 100644 --- a/block/replication.c +++ b/block/replication.c @@ -454,6 +454,7 @@ static void replication_start(ReplicationState *rs, ReplicationMode mode, int64_t active_length, hidden_length, disk_length; AioContext *aio_context; Error *local_err = NULL; + BackupPerf perf = { .use_copy_range = true }; aio_context = bdrv_get_aio_context(bs); aio_context_acquire(aio_context); @@ -558,6 +559,7 @@ static void replication_start(ReplicationState *rs, ReplicationMode mode, s->backup_job = backup_job_create( NULL, s->secondary_disk->bs, s->hidden_disk->bs, 0, MIRROR_SYNC_MODE_NONE, NULL, 0, false, NULL, + &perf, BLOCKDEV_ON_ERROR_REPORT, BLOCKDEV_ON_ERROR_REPORT, JOB_INTERNAL, backup_job_completed, bs, NULL, &local_err); diff --git a/blockdev.c b/blockdev.c index fe6fb5dc1d..b71ed08a3b 100644 --- a/blockdev.c +++ b/blockdev.c @@ -2788,6 +2788,7 @@ static BlockJob *do_backup_common(BackupCommon *backup, { BlockJob *job = NULL; BdrvDirtyBitmap *bmap = NULL; + BackupPerf perf = { .use_copy_range = true }; int job_flags = JOB_DEFAULT; if (!backup->has_speed) { @@ -2812,6 +2813,12 @@ static BlockJob *do_backup_common(BackupCommon *backup, backup->compress = false; } + if (backup->x_perf) { + if (backup->x_perf->has_use_copy_range) { + perf.use_copy_range = backup->x_perf->use_copy_range; + } + } + if ((backup->sync == MIRROR_SYNC_MODE_BITMAP) || (backup->sync == MIRROR_SYNC_MODE_INCREMENTAL)) { /* done before desugaring 'incremental' to print the right message */ @@ -2885,6 +2892,7 @@ static BlockJob *do_backup_common(BackupCommon *backup, backup->sync, bmap, backup->bitmap_mode, backup->compress, backup->filter_node_name, + &perf, backup->on_source_error, backup->on_target_error, job_flags, NULL, NULL, txn, errp);
Experiments show, that copy_range is not always making things faster. So, to make experimentation simpler, let's add a parameter. Some more perf parameters will be added soon, so here is a new struct. For now, add new backup qmp parameter with x- prefix for the following reasons: - We are going to add more performance parameters, some will be related to the whole block-copy process, some only to background copying in backup (ignored for copy-before-write operations). - On the other hand, we are going to use block-copy interface in other block jobs, which will need performance options as well.. And it should be the same structure or at least somehow related. So, there are too much unclean things about how the interface and now we need the new options mostly for testing. Let's keep them experimental for a while. In do_backup_common() new x-perf parameter handled in a way to make further options addition simpler. We add use-copy-range with default=true, and we'll change the default in further patch, after moving backup to use block-copy. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> --- qapi/block-core.json | 17 ++++++++++++++++- block/backup-top.h | 1 + include/block/block-copy.h | 2 +- include/block/block_int.h | 3 +++ block/backup-top.c | 4 +++- block/backup.c | 6 +++++- block/block-copy.c | 4 ++-- block/replication.c | 2 ++ blockdev.c | 8 ++++++++ 9 files changed, 41 insertions(+), 6 deletions(-)