Am 05.10.2016 um 17:13 hat Max Reitz geschrieben: > 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.
I'm not sure if we want to support such syntax in QMP. It sounds like a typical convenience option for human users. > 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. If we want easy, make it easy: cache-coverage and apply it to both. Kevin
pgpvbiNn_Ig2T.pgp
Description: PGP signature