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

Re: [libvirt] [PATCH 3/3] qemu: support metadata-cache-size for blockdev

On 02.11.2018 13:23, Kevin Wolf wrote:
> Am 01.11.2018 um 12:32 hat Nikolay Shirokovskiy geschrieben:
>> Just set l2-cache-size to INT64_MAX for all format nodes of
>> qcow2 type in block node graph.
>> AFAIK this is sane because *actual* cache size depends on size
>> of data being referenced in image and thus the total size of
>> all cache sizes for all images in disk backing chain will not
>> exceed the cache size that covers just one full image as in
>> case of no backing chain.
> This is not quite correct.
> Starting from qemu 3.1, INT64_MAX will add a cache that covers the whole
> image. Memory is only used if a cache entry is actually used, so if you
> never access the backing file, it doesn't really use any memory.
> However, the granularity isn't a single cluster here, but L2 tables. So
> if some L2 table contains one cluster in the overlay and another cluster
> in the backing file, and both are accessed, the L2 table will be cached
> in both the overlay and th backing file.

So we can end up N times bigger memory usage for L2 cache in case
of backing chain comparing to single image?

> More importantly, before 3.1, I think QEMU will actually try to allocate
> 2^63-1 bytes for the cache and fail to open the image. So we can't do
> this unconditionally.
> (Is this patch tested with a real QEMU?)

Test was quite minimal: upstream and 2.10 but with recent patches that
makes setting INT64_MAX possible I guess.

Ok then we have to use version check in capabilities instead of feature test.


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