Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes

[Kevin Wolf <kwolf@redhat.com>]

[ Restoring the CC list, adding Eric for QAPI ]

Am 06.10.2016 um 20:36 hat Frank Myhr geschrieben:
> Thanks Alberto for pointing me to Ed Swierk's patch and this discussion.
> 
> On Wed 05 Oct 2016 16:57:57 +0200, Alberto Garcia wrote:
> 
> > 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
> >
> > [This] would change however the data type of
> > 'l2-cache-size' from int to string in BlockdevOptionsQcow2, can we
> > actually do that?
> 
> Maybe pass a negative integer to indicate percentage, so string is not required?:
> l2-cache-size=-100    (l2-cache-size=max, covers entire drive)
> l2-cache-size=-50     (l2-cache-size=50% of max, covers half of drive)
> l2-cache-size=2097152 (l2-cache-size=2M)

No, this is the kind of magic that is best to avoid.

If you want to have two different ways to configure the cache, make it
two different options.

> On Wed 5 Oct 2016 17:13:39 +0200, Max Reitz wrote;
> 
> > 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.
> 
> On Wed 5 Oct 2016 17:24:08 +0200, Kevin Wolf wrote:
> 
> > If we want easy, make it easy: cache-coverage and apply it to both.
> 
> refcount-cache-size if unspecified is now automatically set to
> l2-cache-size / 4, correct? So if we could specify l2-cache-size as
> "max" or in percentage, it seems that refcount-cache-size is already
> taken care if we if just leave it unspecified.

Yes.

> On Thu 06 Oct 2016 16:34:16 +0200, Alberto Garcia wrote:
> > I don't think it's a good
> > idea to have two ways to specify exactly the same thing, when one can be
> > converted to the other with a very simple operation.
> 
> I agree. For better or worse we already have l2-cache-size. If its
> accepted values can be slightly expanded, using either a "max" enum
> as Max Reitz suggested, or somehow indicating a relative
> (percentage) value rather than an absolute number of bytes, this
> seems to offer sufficient flexibility for a broad range of users.
> 
> Although the percentage of max l2 cache size isn't exactly an
> intuitive number to specify, it's also (as Alberto notes) equal to
> the percentage of drive size covered by the cache. That's only
> marginally harder to think about than the absolute drive size
> covered by cache that a cache-coverage parameter would specify.

I think we can add "max" as an additional accepted value to
l2-cache-size, but if we want to allow percentages, that should be a
separate option (because we can't easily parse "50%" with QAPI except if
treating it as a string, but that wouldn't be quite right).

Kevin