Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes

[Max Reitz]

On 05.10.2016 17:19, Alberto Garcia wrote:
> On Wed 05 Oct 2016 05:13:39 PM CEST, Max Reitz wrote:
> 
>>>>> At least giving users a way to skip the math would be an
>>>>> improvement.  Would you be okay with an explicitly-set option like
>>>>> l2_cache_size=auto or =max that optimizes for performance at the
>>>>> expense of memory?
>>>>
>>> Frank Myhr's suggestion (in bugzilla) is that we allow specifying a %
>>> of the disk size, so
>>>
>>> l2-cache-size=100%  (that would be cache-size=max)
>>> l2-cache-size=80%
> 
>> For me, either works fine.
>>
>> Apart from that, I have to say I think it would be a bit more useful
>> if one would specify the area covered by the metadata caches as an
>> absolute number instead of a relative one (I guess it's generally
>> easier to know what area your applications will perform random
>> accesses on than the relative size, but maybe that's just me).
> 
> I'm not sure if I'm following you, can you give an example of what the
> area covered by the cache exactly means?

Let's take the L2 table cache. Every eight bytes of that cache point to
one cluster in the image, so if it's 8 MB in size, for instance, then
you can cover 1M clusters. With the default 64 kB clusters, you would
cover 64 GB of any image (although you have some constraints on that
range, of course; an 8 MB cache would contain not just 1M cluster
pointers but actually 128 L2 tables (8 MB / 64 kB), so it would actually
cover 128 continuous 512 MB ranges).

So as long as you perform any kind of access pattern within these 64 GB,
the cache will cover that. But when you're doing random accesses over
more than 64 GB, the cache cannot cover it.

So that's what I mean with coverage: The area you can access without
having to suffer cache misses.

Max

signature.asc
Description: OpenPGP digital signature