[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qcow2: Fix the calculation of the maximum L2 ca
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] qcow2: Fix the calculation of the maximum L2 cache size |
Date: |
Fri, 16 Aug 2019 16:08:19 +0200 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
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