qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-stable] [PATCH] qcow2: Fix the calculation of the maximum L2 c


From: Kevin Wolf
Subject: Re: [Qemu-stable] [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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]