Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time

[Max Reitz <mreitz@redhat.com>]

On 28.05.2015 17:13, Eric Blake wrote:
> On 05/28/2015 08:56 AM, Max Reitz wrote:
>> On 27.05.2015 11:46, Alberto Garcia wrote:
>>> This adds a new 'cache-clean-interval' option that cleans all qcow2
>>> cache entries that haven't been used in a certain interval, given in
>>> seconds.
>>>
>>> This allows setting a large L2 cache size so it can handle scenarios
>>> with lots of I/O and at the same time use little memory during periods
>>> of inactivity.
>>>
>>> This feature currently relies on MADV_DONTNEED to free that memory, so
>>> it is not useful in systems that don't follow that behavior.
>>>
>>> +++ b/qapi/block-core.json
>>> @@ -41,6 +41,10 @@
>>>    # @corrupt: #optional true if the image has been marked corrupt;
>>> only valid for
>>>    #           compat >= 1.1 (since 2.2)
>>>    #
>>> +# @cache-clean-interval: interval in seconds after which unused L2 and
>>> +#                        refcount cache entries are removed. If 0 then
>>> +#                        this feature is not enabled (since 2.4)
>>> +#
>>>    # @refcount-bits: width of a refcount entry in bits (since 2.3)
>>>    #
>>>    # Since: 1.7
>>> @@ -50,7 +54,8 @@
>>>          'compat': 'str',
>>>          '*lazy-refcounts': 'bool',
>>>          '*corrupt': 'bool',
>>> -      'refcount-bits': 'int'
>>> +      'refcount-bits': 'int',
>>> +      'cache-clean-interval': 'int'
>>>      } }
>> I'm not too happy about making this part of ImageInfoSpecificQCow2. Two
>> reasons for this: First, it's eventually part of ImageInfo, which is
>> defined as "Information about a QEMU image file", but this option cannot
>> be set in the image file itself but is only a run-time option.
>>
>> Second, my original goal for ImageInfoSpecific was to provide more
>> information through qemu-img info, and this value will look pretty
>> strange there.
>>
>> I don't know how to resolve this quandary, though. Since qemu cannot
>> change this interval by itself, I think not providing an interface for
>> reading it is fine. On the other hand, if Eric finds such an interface
>> absolutely mandatory, I can't think of a better place to return it than
>> here.
> Can we mark the parameter optional, and only provide it when it is
> non-zero?  That way, qemu-img (which cannot set an interval) will not
> report it, and the only time it will appear is if it was set as part of
> opening the block device under qemu.

That sounds good.

Max

>> The only solution which would satisfy both requirements would be another
>> structure which contains "online" flags, and thus is not evaluated by
>> qemu-img info, but only by QMP commands. But that's ugly.
>>
> Yeah, I'm not sure such duplication helps.  I'd still like it reported
> somewhere, though, as it is nice to query that a requested setting is
> actually working.
>