From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: Alberto Garcia <berto@igalia.com>,
Leonid Bloch <lbloch@janustech.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v7 6/9] qcow2: Increase the default upper limit on the L2 cache size
Date: Mon, 13 Aug 2018 18:24:21 +0200 [thread overview]
Message-ID: <20180813162421.GN4323@localhost.localdomain> (raw)
In-Reply-To: <5436d747-9cf3-50a0-6fab-537fb8cc8bae@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]
Am 13.08.2018 um 18:08 hat Max Reitz geschrieben:
> >>> default should reflect that, especially considering that we only use
> >>> the memory on demand. If your image is only 32 GB, you'll never use more
> >>> than 4 MB of cache.
> >>
> >> Well, OK, yes. This is an especially important point when it really is
> >> about hosts that have limited memory. In those cases, users probably
> >> won't run huge images anyway.
> >>
> >>> And if your image is huge, but only access part of
> >>> it, we also won't use the full 32 MB.
> >>
> >> On Linux. O:-)
> >
> > No, on any system where qemu_try_blockalign() results in a COW zero
> > page.
>
> OK, yes, but why would you only ever access part of it? Then you might
> just as well have created a smaller disk from the beginning.
I always create my qcow2 images larger than I actually need them. It
costs basically nothing and avoids the need to resize my partitions
inside the guest later.
And anyway, a disk with 100% usage is not the common case, but the point
where the user will either delete stuff or resize the image. For
long-running VMs, deleting stuff doesn't get rid of the large cache on
non-Linux, but I think we agree that long-running guests aren't what we
expect on those hosts?
> > The Linux-only addition is returning memory even after an access.
> >
> >> So it's good that you have calmed my nerves about how this might be
> >> problematic on Linux systems (it isn't in practice, although I disagree
> >> that people will find qcow2 to be the fault when their memory runs out),
> >> but you haven't said anything about non-Linux systems. I understand
> >> that you don't care, but as I said here, this was my only substantial
> >> concern anyway.
> >
> > I don't actually think it's so bad to keep the cache permanently
> > allocated, but I wouldn't object to a lower default for non-Linux hosts
> > either. 1 MB may still be a little too low, 4 MB (covers up to 32 GB)
> > might be more adequate. My typical desktop VMs are larger than 8 GB, but
> > smaller than 32 GB.
>
> Will your typical desktop VMs gain anything from the cache covering
> more than 8 GB?
Good point. Probably not.
> Anyway, I certainly won't complain about 4 MB.
>
> (My point here is that on non-Linux systems, qemu probably does not have
> users who have use cases where they need to access 256 GB of disk
> simultaneously. Probably not even more than 8 GB. If you want to
> increase the cache size there to 4 MB, fine, I think that won't hurt.
> But 32 MB might hurt, and I don't think on non-Linux systems there are
> users who would benefit from it -- specifically because your "typical
> desktop VM" wouldn't benefit from it.)
Maybe 1 MB is fine for them, after all.
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2018-08-13 16:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-10 6:26 [Qemu-devel] [PATCH v7 0/9] Take the image size into account when allocating the L2 cache Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 1/9] qcow2: Options' documentation fixes Leonid Bloch
2018-08-10 11:50 ` Alberto Garcia
2018-08-11 18:01 ` Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 2/9] qcow2: Cosmetic changes Leonid Bloch
2018-08-10 12:54 ` Alberto Garcia
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 3/9] qcow2: Make sizes more humanly readable Leonid Bloch
2018-08-10 8:33 ` Alberto Garcia
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 4/9] qcow2: Avoid duplication in setting the refcount cache size Leonid Bloch
2018-08-10 13:14 ` Alberto Garcia
2018-08-11 18:40 ` Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 5/9] qcow2: Assign the L2 cache relatively to the image size Leonid Bloch
2018-08-10 14:39 ` Alberto Garcia
2018-08-11 19:19 ` Leonid Bloch
2018-08-13 11:33 ` Kevin Wolf
2018-08-13 11:48 ` Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 6/9] qcow2: Increase the default upper limit on the L2 cache size Leonid Bloch
2018-08-10 12:00 ` Alberto Garcia
2018-08-13 1:39 ` Max Reitz
2018-08-13 6:09 ` Leonid Bloch
2018-08-13 15:16 ` Max Reitz
2018-08-13 16:00 ` Kevin Wolf
2018-08-13 11:23 ` Kevin Wolf
2018-08-13 15:11 ` Max Reitz
2018-08-13 15:58 ` Kevin Wolf
2018-08-13 16:08 ` Max Reitz
2018-08-13 16:24 ` Kevin Wolf [this message]
2018-08-13 16:42 ` Leonid Bloch
2018-08-14 8:18 ` Kevin Wolf
2018-08-14 11:34 ` Leonid Bloch
2018-08-14 11:44 ` Kevin Wolf
2018-08-14 12:29 ` Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 7/9] qcow2: Resize the cache upon image resizing Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 8/9] qcow2: Set the default cache-clean-interval to 10 minutes Leonid Bloch
2018-08-10 6:26 ` [Qemu-devel] [PATCH v7 9/9] qcow2: Explicit number replaced by a constant Leonid Bloch
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=20180813162421.GN4323@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=eblake@redhat.com \
--cc=lbloch@janustech.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.