qemu-block
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time
Date: Thu, 28 May 2015 18:44:55 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 28.05.2015 um 17:13 hat Eric Blake geschrieben:
> 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.

No, that wouldn't be right. It's not information tied to the image file.

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

This isn't duplicated information. You can have ImageInfoSpecificQCow2
show lazy_refcounts=off because that is what the image file contains,
but the real value in effect could be lazy_refcounts=on.

Options stored in the image and runtime options are two different pieces
of information, even if the former specify the defaults for the latter.
So I think it should be possible to query both of them.

Kevin

Attachment: pgpX9udOqZv2X.pgp
Description: PGP signature


reply via email to

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