From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Max Reitz <mreitz@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: "fam@euphon.net" <fam@euphon.net>,
"kwolf@redhat.com" <kwolf@redhat.com>,
Denis Lunev <den@virtuozzo.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"armbru@redhat.com" <armbru@redhat.com>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"jsnow@redhat.com" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/8] block/backup: improve unallocated clusters skipping
Date: Fri, 9 Aug 2019 07:50:05 +0000 [thread overview]
Message-ID: <ba8ea007-06dd-03fb-9f9c-6e31a4764156@virtuozzo.com> (raw)
In-Reply-To: <23fd227d-9074-3a9e-b6c7-09f4abadc021@redhat.com>
07.08.2019 21:01, Max Reitz wrote:
> On 07.08.19 10:07, Vladimir Sementsov-Ogievskiy wrote:
>> Limit block_status querying to request bounds on write notifier to
>> avoid extra seeking.
>
> I don’t understand this reasoning. Checking whether something is
> allocated for qcow2 should just mean an L2 cache lookup. Which we have
> to do anyway when we try to copy data off the source.
But for raw it's seeking. I think we just shouldn't do any unnecessary operations
in copy-before-write handling. So instead of calling
block_status(request_start, disk_end) I think it's better to call
block_status(request_start, request_end). And it is more applicable for reusing this
code too.
>
> I could understand saying this makes the code easier, but I actually
> don’t think it does. If you implemented checking the allocation status
> only for areas where the bitmap is reset (which I think this patch
> should), then it’d just duplicate the existing loop.
>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---
>> block/backup.c | 38 +++++++++++++++++++++-----------------
>> 1 file changed, 21 insertions(+), 17 deletions(-)
>>
>> diff --git a/block/backup.c b/block/backup.c
>> index 11e27c844d..a4d37d2d62 100644
>> --- a/block/backup.c
>> +++ b/block/backup.c
>
> [...]
>
>> @@ -267,6 +267,18 @@ static int coroutine_fn backup_do_cow(BackupBlockJob *job,
>> wait_for_overlapping_requests(job, start, end);
>> cow_request_begin(&cow_request, job, start, end);
>>
>> + if (job->initializing_bitmap) {
>> + int64_t off, chunk;
>> +
>> + for (off = offset; offset < end; offset += chunk) {
>
> This is what I’m referring to, I think this loop should skip areas that
> are clean.
Agree, will do.
>
>> + ret = backup_bitmap_reset_unallocated(job, off, end - off, &chunk);
>> + if (ret < 0) {
>> + chunk = job->cluster_size;
>> + }
>> + }
>> + }
>> + ret = 0;
>> +
>> while (start < end) {
>> int64_t dirty_end;
>>
>> @@ -276,15 +288,6 @@ static int coroutine_fn backup_do_cow(BackupBlockJob *job,
>> continue; /* already copied */
>> }
>>
>> - if (job->initializing_bitmap) {
>> - ret = backup_bitmap_reset_unallocated(job, start, &skip_bytes);
>> - if (ret == 0) {
>> - trace_backup_do_cow_skip_range(job, start, skip_bytes);
>> - start += skip_bytes;
>> - continue;
>> - }
>> - }
>> -
>> dirty_end = bdrv_dirty_bitmap_next_zero(job->copy_bitmap, start,
>> end - start);
>> if (dirty_end < 0) {
>
> Hm, you resolved that conflict differently from me.
>
> I decided the bdrv_dirty_bitmap_next_zero() call should go before the
> backup_bitmap_reset_unallocated() call so that we can then do a
>
> dirty_end = MIN(dirty_end, start + skip_bytes);
>
> because we probably don’t want to copy anything past what
> backup_bitmap_reset_unallocated() has inquired.
>
>
> But then again this patch eliminates the difference anyway...
> >
>> @@ -546,7 +549,8 @@ static int coroutine_fn backup_run(Job *job, Error **errp)
>> goto out;
>> }
>>
>> - ret = backup_bitmap_reset_unallocated(s, offset, &count);
>> + ret = backup_bitmap_reset_unallocated(s, offset, s->len - offset,
>> + &count);
>> if (ret < 0) {
>> goto out;
>> }
>>
>
>
--
Best regards,
Vladimir
next prev parent reply other threads:[~2019-08-09 7:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 8:07 [Qemu-devel] [PATCH 0/8] backup improvements Vladimir Sementsov-Ogievskiy
2019-08-07 8:07 ` [Qemu-devel] [PATCH 1/8] block/backup: deal with zero detection Vladimir Sementsov-Ogievskiy
2019-08-07 8:07 ` [Qemu-devel] [PATCH 2/8] block/backup: refactor write_flags Vladimir Sementsov-Ogievskiy
2019-08-07 16:53 ` Max Reitz
2019-08-07 8:07 ` [Qemu-devel] [PATCH 3/8] block/io: handle alignment and max_transfer for copy_range Vladimir Sementsov-Ogievskiy
2019-08-07 17:28 ` Max Reitz
2019-08-09 7:50 ` Vladimir Sementsov-Ogievskiy
2019-08-07 8:07 ` [Qemu-devel] [PATCH 4/8] block/backup: improve unallocated clusters skipping Vladimir Sementsov-Ogievskiy
2019-08-07 18:01 ` Max Reitz
2019-08-09 7:50 ` Vladimir Sementsov-Ogievskiy [this message]
2019-08-09 9:12 ` Vladimir Sementsov-Ogievskiy
2019-08-09 10:25 ` Vladimir Sementsov-Ogievskiy
2019-08-09 10:10 ` Vladimir Sementsov-Ogievskiy
2019-08-09 12:25 ` Max Reitz
2019-08-09 12:47 ` Vladimir Sementsov-Ogievskiy
2019-08-09 12:53 ` Max Reitz
2019-08-07 8:07 ` [Qemu-devel] [PATCH 5/8] block/backup: fix backup_cow_with_offload for last cluster Vladimir Sementsov-Ogievskiy
2019-08-07 18:05 ` Max Reitz
2019-08-07 8:07 ` [Qemu-devel] [PATCH 6/8] block/backup: teach backup_cow_with_bounce_buffer to copy more at once Vladimir Sementsov-Ogievskiy
2019-08-07 18:25 ` Max Reitz
2019-08-07 8:07 ` [Qemu-devel] [PATCH 7/8] block/backup: merge duplicated logic into backup_do_cow Vladimir Sementsov-Ogievskiy
2019-08-07 18:37 ` Max Reitz
2019-08-07 8:07 ` [Qemu-devel] [PATCH 8/8] block/backup: backup_do_cow: use bdrv_dirty_bitmap_next_dirty_area Vladimir Sementsov-Ogievskiy
2019-08-07 18:46 ` Max Reitz
2019-08-09 7:54 ` Vladimir Sementsov-Ogievskiy
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=ba8ea007-06dd-03fb-9f9c-6e31a4764156@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=den@virtuozzo.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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).