From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: Leonid Bloch <lbloch@janustech.com>,
Max Reitz <mreitz@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qcow2: Fix the calculation of the maximum L2 cache size
Date: Fri, 16 Aug 2019 16:08:19 +0200 [thread overview]
Message-ID: <20190816140819.GD5014@localhost.localdomain> (raw)
In-Reply-To: <w51lfvti6fs.fsf@maestria.local.igalia.com>
Am 16.08.2019 um 15:30 hat Alberto Garcia geschrieben:
> On Fri 16 Aug 2019 02:59:21 PM CEST, Kevin Wolf wrote:
> > The requirement so that this bug doesn't affect the user seems to be
> > that the image size is a multiple of 64k * 8k = 512 MB. Which means
> > that users are probably often lucky enough in practice.
>
> Or rather: cluster_size^2 / 8, which, if my numbers are right:
>
> |--------------+-------------|
> | Cluster size | Multiple of |
> |--------------+-------------|
> | 4 KB | 2 MB |
> | 8 KB | 8 MB |
> | 16 KB | 32 MB |
> | 32 KB | 128 MB |
> | 64 KB | 512 MB |
> | 128 KB | 2 GB |
> | 256 KB | 8 GB |
> | 512 KB | 32 GB |
> | 1024 KB | 128 GB |
> | 2048 KB | 512 GB |
> |--------------+-------------|
>
> It get trickier with larger clusters, but if you have a larger cluster
> size you probably have a very large image anyway, so yes I also think
> that users are probably lucky enough in practice.
Yes, I assumed 64k clusters.
The other somewhat popular cluster size is probably 2 MB, where I think
images sizes that are not a multiple of 512 GB are rather likely...
> (also, the number of cache tables is always >= 2, so if the image size
> is less than twice those numbers then it's also safe)
Right. I already corrected my statement to include > 1024 MB in the Red
Hat Bugzilla (but still didn't consider other cluster sizes).
> And yes, the odd value on the 512KB row on that we discussed last month
> is due to this same bug:
>
> https://lists.gnu.org/archive/html/qemu-block/2019-07/msg00496.html
Hm... And suddently it makes sense. :-)
So I assume all of 512k/1024k/2048k actually perform better? Or is the
effect neglegible for 1024k/2048k?
Kevin
next prev parent reply other threads:[~2019-08-16 14:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 12:17 [Qemu-devel] [PATCH] qcow2: Fix the calculation of the maximum L2 cache size Alberto Garcia
2019-08-16 12:41 ` Alberto Garcia
2019-08-16 12:59 ` Kevin Wolf
2019-08-16 13:30 ` Alberto Garcia
2019-08-16 14:08 ` Kevin Wolf [this message]
2019-08-16 14:25 ` Alberto Garcia
2019-08-18 10:17 ` 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=20190816140819.GD5014@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=lbloch@janustech.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).