[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache ent

From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time
Date: Thu, 28 May 2015 17:14:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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

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
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.


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.

reply via email to

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