qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on im


From: Frank Myhr
Subject: Re: [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes
Date: Thu, 6 Oct 2016 14:36:15 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

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)


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.


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.

Frank



reply via email to

[Prev in Thread] Current Thread [Next in Thread]