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. Nikolay -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
