From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-block@nongnu.org
Cc: kwolf@redhat.com, den@openvz.org, qemu-devel@nongnu.org,
armbru@redhat.com
Subject: Re: [PATCH 3/7] block/qcow2: use compressed write cache
Date: Wed, 10 Feb 2021 18:11:21 +0100 [thread overview]
Message-ID: <446ebfd5-ac72-dc18-fde3-6cc7ffa73176@redhat.com> (raw)
In-Reply-To: <20210129165030.640169-4-vsementsov@virtuozzo.com>
On 29.01.21 17:50, Vladimir Sementsov-Ogievskiy wrote:
> Introduce a new option: compressed-cache-size, with default to 64
> clusters (to be not less than 64 default max-workers for backup job).
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> qapi/block-core.json | 8 +++-
> block/qcow2.h | 4 ++
> block/qcow2-refcount.c | 13 +++++++
> block/qcow2.c | 87 ++++++++++++++++++++++++++++++++++++++++--
> 4 files changed, 108 insertions(+), 4 deletions(-)
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 9f555d5c1d..e0be6657f3 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -3202,6 +3202,11 @@
> # an image, the data file name is loaded from the image
> # file. (since 4.0)
> #
> +# @compressed-cache-size: The maximum size of compressed write cache in
> +# bytes. If positive must be not less than
> +# cluster size. 0 disables the feature. Default
> +# is 64 * cluster_size. (since 6.0)
Do we need this, really? If you don’t use compression, the cache won’t
use any memory, right? Do you plan on using this option?
I’d just set it to a sane default.
OTOH, “a sane default” poses two questions, namely whether 64 *
cluster_size is reasonable – with subclusters, the cluster size may be
rather high, so 64 * cluster_size may well be like 128 MB. Are 64
clusters really necessary for a reasonable performance?
Second, I think I could live with a rather high default if clusters are
flushed as soon as they are full. OTOH, as I briefly touched on, in
practice, I suppose compressed images are just written to constantly, so
even if clusters are flushed as soon as they are full, the cache will
still remain full all the time.
Different topic: Why is the cache disableable? I thought there are no
downsides?
(Not being able to disable it would make the code simpler, hence me asking.)
Max
next prev parent reply other threads:[~2021-02-10 17:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 16:50 [PATCH 0/7] qcow2: compressed write cache Vladimir Sementsov-Ogievskiy
2021-01-29 16:50 ` [PATCH 1/7] qemu/queue: add some useful QLIST_ and QTAILQ_ macros Vladimir Sementsov-Ogievskiy
2021-02-01 8:29 ` Markus Armbruster
2021-02-01 8:34 ` Vladimir Sementsov-Ogievskiy
2021-02-10 17:07 ` Max Reitz
2021-01-29 16:50 ` [PATCH 2/7] block/qcow2: introduce cache for compressed writes Vladimir Sementsov-Ogievskiy
2021-02-10 17:07 ` Max Reitz
2021-02-11 12:49 ` Vladimir Sementsov-Ogievskiy
2021-02-18 15:04 ` Max Reitz
2021-01-29 16:50 ` [PATCH 3/7] block/qcow2: use compressed write cache Vladimir Sementsov-Ogievskiy
2021-02-10 17:11 ` Max Reitz [this message]
2021-02-11 12:53 ` Vladimir Sementsov-Ogievskiy
2021-02-18 16:02 ` Max Reitz
2021-01-29 16:50 ` [PATCH 4/7] simplebench: bench_one(): add slow_limit argument Vladimir Sementsov-Ogievskiy
2021-01-29 16:50 ` [PATCH 5/7] simplebench: bench_one(): support count=1 Vladimir Sementsov-Ogievskiy
2021-01-29 16:50 ` [PATCH 6/7] simplebench/bench-backup: add --compressed option Vladimir Sementsov-Ogievskiy
2021-01-29 16:50 ` [PATCH 7/7] simplebench/bench-backup: add target-cache argument Vladimir Sementsov-Ogievskiy
2021-01-29 17:30 ` [PATCH 0/7] qcow2: compressed write cache no-reply
2021-02-01 8:24 ` Vladimir Sementsov-Ogievskiy
2021-02-09 13:25 ` Max Reitz
2021-02-09 14:10 ` Vladimir Sementsov-Ogievskiy
2021-02-09 14:47 ` Max Reitz
2021-02-09 16:39 ` Vladimir Sementsov-Ogievskiy
2021-02-09 18:36 ` Vladimir Sementsov-Ogievskiy
2021-02-09 18:41 ` Denis V. Lunev
2021-02-09 18:51 ` Vladimir Sementsov-Ogievskiy
2021-02-10 10:00 ` Max Reitz
2021-02-10 10:10 ` Vladimir Sementsov-Ogievskiy
2021-02-09 16:52 ` Denis V. Lunev
2021-02-10 10:00 ` Max Reitz
2021-02-10 12:35 ` Kevin Wolf
2021-02-10 14:35 ` 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=446ebfd5-ac72-dc18-fde3-6cc7ffa73176@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).