qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com,
	qemu-devel@nongnu.org, mreitz@redhat.com, den@openvz.org,
	jsnow@redhat.com
Subject: [PATCH 2/6] block/block-copy: limit copy_range_size to 16 MiB
Date: Thu,  3 Oct 2019 20:15:35 +0300	[thread overview]
Message-ID: <20191003171539.12327-3-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20191003171539.12327-1-vsementsov@virtuozzo.com>

Large copy range may imply memory allocation and large io effort, so
using 2G copy range request may be bad idea. Let's limit it to 16 MiB.
It also helps the following patch to refactor copy-with-offload
fallback to copy-with-bounce-buffer.

Note, that total memory usage of backup is still not limited, it will
be fixed in further commit.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 block/block-copy.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/block/block-copy.c b/block/block-copy.c
index aca0f893d7..75287ce24d 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -18,6 +18,9 @@
 #include "qapi/error.h"
 #include "block/block-copy.h"
 #include "sysemu/block-backend.h"
+#include "qemu/units.h"
+
+#define BLOCK_COPY_MAX_COPY_RANGE (16 * MiB)
 
 static void coroutine_fn block_copy_wait_inflight_reqs(BlockCopyState *s,
                                                        int64_t start,
@@ -70,9 +73,12 @@ BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target,
 {
     BlockCopyState *s;
     BdrvDirtyBitmap *copy_bitmap;
+
+    /* Ignore BLOCK_COPY_MAX_COPY_RANGE if requested cluster_size is larger */
     uint32_t max_transfer =
-            MIN_NON_ZERO(INT_MAX, MIN_NON_ZERO(source->bs->bl.max_transfer,
-                                               target->bs->bl.max_transfer));
+            MIN_NON_ZERO(MAX(cluster_size, BLOCK_COPY_MAX_COPY_RANGE),
+                         MIN_NON_ZERO(source->bs->bl.max_transfer,
+                                      target->bs->bl.max_transfer));
 
     copy_bitmap = bdrv_create_dirty_bitmap(source->bs, cluster_size, NULL,
                                            errp);
-- 
2.21.0



  parent reply	other threads:[~2019-10-03 17:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 17:15 [PATCH 0/6] block-copy: memory limit Vladimir Sementsov-Ogievskiy
2019-10-03 17:15 ` [PATCH 1/6] block/block-copy: allocate buffer in block_copy_with_bounce_buffer Vladimir Sementsov-Ogievskiy
2019-10-07 13:30   ` Max Reitz
2019-10-03 17:15 ` Vladimir Sementsov-Ogievskiy [this message]
2019-10-07 13:40   ` [PATCH 2/6] block/block-copy: limit copy_range_size to 16 MiB Max Reitz
2019-10-03 17:15 ` [PATCH 3/6] block/block-copy: refactor copying Vladimir Sementsov-Ogievskiy
2019-10-07 14:17   ` Max Reitz
2019-10-07 16:29     ` Vladimir Sementsov-Ogievskiy
2019-10-03 17:15 ` [PATCH 4/6] util: introduce co-shared-amount Vladimir Sementsov-Ogievskiy
2019-10-07 15:22   ` Max Reitz
2019-10-07 16:49     ` Vladimir Sementsov-Ogievskiy
2019-10-03 17:15 ` [PATCH 5/6] block/block-copy: add memory limit Vladimir Sementsov-Ogievskiy
2019-10-07 15:27   ` Max Reitz
2019-10-07 17:10     ` Vladimir Sementsov-Ogievskiy
2019-10-08  9:03       ` Max Reitz
2019-10-08  9:15         ` Vladimir Sementsov-Ogievskiy
2019-10-08  9:20           ` Vladimir Sementsov-Ogievskiy
2019-10-08  9:57             ` Max Reitz
2019-10-08  9:56           ` Max Reitz
2019-10-03 17:15 ` [PATCH 6/6] block/block-copy: increase buffered copy request Vladimir Sementsov-Ogievskiy
2019-10-07 15:47   ` Max Reitz
2019-10-07 15:48   ` Max Reitz
2019-10-07 16:22     ` 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=20191003171539.12327-3-vsementsov@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@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).