From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com,
qemu-stable@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
andrey.shinkevich@virtuozzo.com, jsnow@redhat.com
Subject: [PATCH v3 2/9] block/block-copy: fix progress calculation
Date: Fri, 6 Mar 2020 10:38:24 +0300 [thread overview]
Message-ID: <20200306073831.7737-3-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20200306073831.7737-1-vsementsov@virtuozzo.com>
Assume we have two regions, A and B, and region B is in-flight now,
region A is not yet touched, but it is unallocated and should be
skipped.
Correspondingly, as progress we have
total = A + B
current = 0
If we reset unallocated region A and call progress_reset_callback,
it will calculate 0 bytes dirty in the bitmap and call
job_progress_set_remaining, which will set
total = current + 0 = 0 + 0 = 0
So, B bytes are actually removed from total accounting. When job
finishes we'll have
total = 0
current = B
, which doesn't sound good.
This is because we didn't considered in-flight bytes, actually when
calculating remaining, we should have set (in_flight + dirty_bytes)
as remaining, not only dirty_bytes.
To fix it, let's refactor progress calculation, moving it to block-copy
itself instead of fixing callback. And, of course, track in_flight
bytes count.
We still have to keep one callback, to maintain backup job bytes_read
calculation, but it will go on soon, when we turn the whole backup
process into one block_copy call.
Cc: qemu-stable@nongnu.org
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
---
include/block/block-copy.h | 14 +++++---------
block/backup.c | 13 ++-----------
block/block-copy.c | 16 ++++++++++++----
3 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/include/block/block-copy.h b/include/block/block-copy.h
index 0a161724d7..dc68c8c54e 100644
--- a/include/block/block-copy.h
+++ b/include/block/block-copy.h
@@ -36,6 +36,7 @@ typedef struct BlockCopyState {
BdrvChild *source;
BdrvChild *target;
BdrvDirtyBitmap *copy_bitmap;
+ int64_t in_flight_bytes;
int64_t cluster_size;
bool use_copy_range;
int64_t copy_size;
@@ -60,15 +61,9 @@ typedef struct BlockCopyState {
*/
bool skip_unallocated;
+ ProgressMeter *progress;
/* progress_bytes_callback: called when some copying progress is done. */
ProgressBytesCallbackFunc progress_bytes_callback;
-
- /*
- * progress_reset_callback: called when some bytes reset from copy_bitmap
- * (see @skip_unallocated above). The callee is assumed to recalculate how
- * many bytes remain based on the dirty bit count of copy_bitmap.
- */
- ProgressResetCallbackFunc progress_reset_callback;
void *progress_opaque;
SharedResource *mem;
@@ -79,12 +74,13 @@ BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target,
BdrvRequestFlags write_flags,
Error **errp);
-void block_copy_set_callbacks(
+void block_copy_set_progress_callback(
BlockCopyState *s,
ProgressBytesCallbackFunc progress_bytes_callback,
- ProgressResetCallbackFunc progress_reset_callback,
void *progress_opaque);
+void block_copy_set_progress_meter(BlockCopyState *s, ProgressMeter *pm);
+
void block_copy_state_free(BlockCopyState *s);
int64_t block_copy_reset_unallocated(BlockCopyState *s,
diff --git a/block/backup.c b/block/backup.c
index 1383e219f5..8694e0394b 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -57,15 +57,6 @@ static void backup_progress_bytes_callback(int64_t bytes, void *opaque)
BackupBlockJob *s = opaque;
s->bytes_read += bytes;
- job_progress_update(&s->common.job, bytes);
-}
-
-static void backup_progress_reset_callback(void *opaque)
-{
- BackupBlockJob *s = opaque;
- uint64_t estimate = bdrv_get_dirty_count(s->bcs->copy_bitmap);
-
- job_progress_set_remaining(&s->common.job, estimate);
}
static int coroutine_fn backup_do_cow(BackupBlockJob *job,
@@ -464,8 +455,8 @@ BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs,
job->cluster_size = cluster_size;
job->len = len;
- block_copy_set_callbacks(bcs, backup_progress_bytes_callback,
- backup_progress_reset_callback, job);
+ block_copy_set_progress_callback(bcs, backup_progress_bytes_callback, job);
+ block_copy_set_progress_meter(bcs, &job->common.job.progress);
/* Required permissions are already taken by backup-top target */
block_job_add_bdrv(&job->common, "target", target, 0, BLK_PERM_ALL,
diff --git a/block/block-copy.c b/block/block-copy.c
index 79798a1567..e2d7b3b887 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -127,17 +127,20 @@ BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target,
return s;
}
-void block_copy_set_callbacks(
+void block_copy_set_progress_callback(
BlockCopyState *s,
ProgressBytesCallbackFunc progress_bytes_callback,
- ProgressResetCallbackFunc progress_reset_callback,
void *progress_opaque)
{
s->progress_bytes_callback = progress_bytes_callback;
- s->progress_reset_callback = progress_reset_callback;
s->progress_opaque = progress_opaque;
}
+void block_copy_set_progress_meter(BlockCopyState *s, ProgressMeter *pm)
+{
+ s->progress = pm;
+}
+
/*
* block_copy_do_copy
*
@@ -269,7 +272,9 @@ int64_t block_copy_reset_unallocated(BlockCopyState *s,
if (!ret) {
bdrv_reset_dirty_bitmap(s->copy_bitmap, offset, bytes);
- s->progress_reset_callback(s->progress_opaque);
+ progress_set_remaining(s->progress,
+ bdrv_get_dirty_count(s->copy_bitmap) +
+ s->in_flight_bytes);
}
*count = bytes;
@@ -331,15 +336,18 @@ int coroutine_fn block_copy(BlockCopyState *s,
trace_block_copy_process(s, start);
bdrv_reset_dirty_bitmap(s->copy_bitmap, start, chunk_end - start);
+ s->in_flight_bytes += chunk_end - start;
co_get_from_shres(s->mem, chunk_end - start);
ret = block_copy_do_copy(s, start, chunk_end, error_is_read);
co_put_to_shres(s->mem, chunk_end - start);
+ s->in_flight_bytes -= chunk_end - start;
if (ret < 0) {
bdrv_set_dirty_bitmap(s->copy_bitmap, start, chunk_end - start);
break;
}
+ progress_work_done(s->progress, chunk_end - start);
s->progress_bytes_callback(chunk_end - start, s->progress_opaque);
start = chunk_end;
ret = 0;
--
2.21.0
next prev parent reply other threads:[~2020-03-06 7:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 7:38 [PATCH v3 0/9] block-copy improvements: part I Vladimir Sementsov-Ogievskiy
2020-03-06 7:38 ` [PATCH v3 1/9] job: refactor progress to separate object Vladimir Sementsov-Ogievskiy
2020-03-10 12:22 ` Andrey Shinkevich
2020-03-10 12:40 ` Max Reitz
2020-03-06 7:38 ` Vladimir Sementsov-Ogievskiy [this message]
2020-03-10 13:32 ` [PATCH v3 2/9] block/block-copy: fix progress calculation Max Reitz
2020-03-06 7:38 ` [PATCH v3 3/9] block/block-copy: specialcase first copy_range request Vladimir Sementsov-Ogievskiy
2020-03-10 13:42 ` Max Reitz
2020-03-06 7:38 ` [PATCH v3 4/9] block/block-copy: use block_status Vladimir Sementsov-Ogievskiy
2020-03-10 14:21 ` Max Reitz
2020-03-06 7:38 ` [PATCH v3 5/9] block/block-copy: factor out find_conflicting_inflight_req Vladimir Sementsov-Ogievskiy
2020-03-10 14:27 ` Max Reitz
2020-03-06 7:38 ` [PATCH v3 6/9] block/block-copy: refactor interfaces to use bytes instead of end Vladimir Sementsov-Ogievskiy
2020-03-10 14:44 ` Max Reitz
2020-03-06 7:38 ` [PATCH v3 7/9] block/block-copy: rename start to offset in interfaces Vladimir Sementsov-Ogievskiy
2020-03-10 14:50 ` Max Reitz
2020-03-10 14:55 ` Andrey Shinkevich
2020-03-10 15:14 ` Max Reitz
2020-03-10 16:15 ` Andrey Shinkevich
2020-03-06 7:38 ` [PATCH v3 8/9] block/block-copy: reduce intersecting request lock Vladimir Sementsov-Ogievskiy
2020-03-10 15:32 ` Max Reitz
2020-03-11 9:39 ` Vladimir Sementsov-Ogievskiy
2020-03-06 7:38 ` [PATCH v3 9/9] block/block-copy: hide structure definitions Vladimir Sementsov-Ogievskiy
2020-03-10 14:55 ` Andrey Shinkevich
2020-03-10 15:38 ` Max Reitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200306073831.7737-3-vsementsov@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=andrey.shinkevich@virtuozzo.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).