On 04.10.2016 17:36, Ed Swierk wrote: > On Tue, Oct 4, 2016 at 7:31 AM, Alberto Garcia <be...@igalia.com> wrote: >> That might be a lot of memory if the image is big. 1 TB qcow2 image == >> 128 MB L2 cache. >> >> See https://bugzilla.redhat.com/show_bug.cgi?id=1377735#c2 >> >> If we want to add this feature, I think I'd rather make it explicit. > > I agree explicit is generally better than automagical, but unlike say > the VM RAM size, the qcow L2 table cache is an implementation detail > no user should be expected to know exists, let alone needs tweaking > according to a specific formula to avoid an arbitrary performance > cliff.
I think a user can be expected to know it when they really want optimal performance for huge workloads. > 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? That (cache-size=max) is actually something Stefan Hajnoczi has proposed at KVM Forum 2015. I agree that implementing the formula in qemu's qcow2 driver itself makes sense and will help users; however, I do think it is appropriate to expect the user to pass cache-size=max if they need it. We shouldn't fix this lack of knowledge by making cache-size=max the default but by documenting it properly (although I'm yet unsure where to do that, other than in some blog...). Also, we have the cache-clean-interval option which makes the qcow2 driver automatically clean up unused entries in the metadata caches, which would be very useful for cache-size=max; we thus shouldn't forget to mention that in the documentation as well. Max
signature.asc
Description: OpenPGP digital signature