From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy0ve-0002B0-3S for qemu-devel@nongnu.org; Thu, 28 May 2015 12:45:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yy0vc-0007NB-EX for qemu-devel@nongnu.org; Thu, 28 May 2015 12:45:09 -0400 Date: Thu, 28 May 2015 18:44:55 +0200 From: Kevin Wolf Message-ID: <20150528164455.GF3385@noname.redhat.com> References: <8007efe81120cd72f7c4145b8bbc3f4bc558e62d.1432719752.git.berto@igalia.com> <55672CA2.10105@redhat.com> <556730A1.40705@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <556730A1.40705@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-block@nongnu.org, Alberto Garcia , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >> >=20 > >> +++ b/qapi/block-core.json > >> @@ -41,6 +41,10 @@ > >> # @corrupt: #optional true if the image has been marked corrupt; > >> only valid for > >> # compat >=3D 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' > >> } } > >=20 > > 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. > >=20 > > Second, my original goal for ImageInfoSpecific was to provide more > > information through qemu-img info, and this value will look pretty > > strange there. > >=20 > > 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. >=20 > 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. > >=20 >=20 > 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=3Doff because that is what the image file contains, but the real value in effect could be lazy_refcounts=3Don. 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 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVZ0YHAAoJEH8JsnLIjy/Wx30P/jBoPDNXqU9DL32Hccow6AeU PbqbOsysrpgmCwGqYSbyZF69LK7m7pc9Fc04ozt5mY0fu7BSv3Pc4y+kRGND1lIp Gss/Y1R/LRNvDIZqX+dKrTBSB/UX0A//NQ3BYC00i/w8Db4eLDoZVfVyfCndtd9C xdbPxKbeZi+ITzKXWXw14iWyBm+aQQzgLDaCmK7Mo1r5zHAWYnlKBk0ZDMcCGVVh kSp6wvRgTjx5zuV9pJoQk5XA9xMPbnN8JIhr+e321qc20V4WviQM6WvB2eTxjDcG NLsRYLjYfUuxK0artTADcQ6ZRKIjqydVFM4N021+ZnpDKswvWfgv1kJExNn3c7QI 7AqPp5q9UMYfRv3Q1WXlA90HBOZRrCnfGwLP39rBKJvb9VvrTTLHkjrJ0G3ZaCVh kax3B5c5Vh1RtLtWxyIDKbogKT89flotE1sl8qCEfyOsaRTuTJB9GIKjBj5rG5nk zOzoBZD5QCBSFpmGrjHnx/35nUQNNVEnzzs12HvStidCOWYMWAHKYlqd6l2nTD8l QZNMgk5hcMG1F860O5ufDl43XUVbAAuPS6QS5p9ZeoKt3a4LChdB0KuNwutr+o1x bUmqzWTBlm8d4/MQF2RKxFU/jzzATuh6Wjza1yYyoZqVAa5TownOc0vy/uk/3wjq Xbu75+Y6gCouWUg/g1ZI =ewmN -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu--