On 05.10.2016 16:57, Alberto Garcia wrote: > On Tue 04 Oct 2016 05:51:26 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? >> >> 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. > > 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% > ... > > https://bugzilla.redhat.com/show_bug.cgi?id=1377735#c3 > > Either one looks good to me. They would change however the data type of > 'l2-cache-size' from int to string in BlockdevOptionsQcow2, can we > actually do that?
I think we can do that with an alternate data type which accepts both an integer and a string. If we only had "max", we'd probably want to make it an enumeration instead of a free-form string, though. But with a % suffix, we'd probably need a string. 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). Supporting that with cache-size is difficult, though, because how are you going to decide between whether the user is specifying the actual size of the cache or the area it covers? So maybe it would make more sense to introduce a whole new set of options called {,l2-,refcount-}cache-coverage or something. These options would then accept both an absolute and a relative number. Max
signature.asc
Description: OpenPGP digital signature