From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bro3Q-0002rH-IF for qemu-devel@nongnu.org; Wed, 05 Oct 2016 11:24:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bro3P-0002FT-8L for qemu-devel@nongnu.org; Wed, 05 Oct 2016 11:24:20 -0400 Date: Wed, 5 Oct 2016 17:24:08 +0200 From: Kevin Wolf Message-ID: <20161005152408.GH1657@noname.str.redhat.com> References: <1475588392-10286-1-git-send-email-eswierk@skyportsystems.com> <909d43bd-a809-074a-16ca-da254035448f@redhat.com> <2e3185e2-6a56-5c1a-eff1-5331d817fc3c@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <2e3185e2-6a56-5c1a-eff1-5331d817fc3c@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Alberto Garcia , Ed Swierk , qemu-devel@nongnu.org, qemu-block@nongnu.org --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 05.10.2016 um 17:13 hat Max Reitz geschrieben: > On 05.10.2016 16:57, Alberto Garcia wrote: > > On Tue 04 Oct 2016 05:51:26 PM CEST, Max Reitz wrote: > >=20 > >>> At least giving users a way to skip the math would be an improvement. > >>> Would you be okay with an explicitly-set option like > >>> l2_cache_size=3Dauto or =3Dmax that optimizes for performance at the > >>> expense of memory? > >> > >> That (cache-size=3Dmax) is actually something Stefan Hajnoczi has > >> proposed at KVM Forum 2015. > >> > >> I agree that implementing the formula in qemu's qcow2 driver itself > >> makes sense and will help users; however, I do think it is appropriate > >> to expect the user to pass cache-size=3Dmax if they need it. > >=20 > > Frank Myhr's suggestion (in bugzilla) is that we allow specifying a % of > > the disk size, so > >=20 > > l2-cache-size=3D100% (that would be cache-size=3Dmax) > > l2-cache-size=3D80% > > ... > >=20 > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1377735#c3 > >=20 > > Either one looks good to me. They would change however the data type of > > 'l2-cache-size' from int to string in BlockdevOptionsQcow2, can we > > actually do that? >=20 > I think we can do that with an alternate data type which accepts both an > integer and a string. If we only had "max", we'd probably want to make > it an enumeration instead of a free-form string, though. But with a % > suffix, we'd probably need a string. >=20 > For me, either works fine. I'm not sure if we want to support such syntax in QMP. It sounds like a typical convenience option for human users. > Apart from that, I have to say I think it would be a bit more useful if > one would specify the area covered by the metadata caches as an absolute > number instead of a relative one (I guess it's generally easier to know > what area your applications will perform random accesses on than the > relative size, but maybe that's just me). >=20 > Supporting that with cache-size is difficult, though, because how are > you going to decide between whether the user is specifying the actual > size of the cache or the area it covers? >=20 > So 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. If we want easy, make it easy: cache-coverage and apply it to both. Kevin --gKMricLos+KVdGMg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJX9RsYAAoJEH8JsnLIjy/WJrgP/058RhHyVOSyNV8/14VwLUtk ykvPJYKKM4XCU+wtYnvQuOyoWJZ/mxDRWawCgXzMBvb/ieXqkvRXwUWd7tt79R/C y2QkR+Msp313dXTr/eybT20XEHKshfV3VHLckSWfol8NIee/I/5BTutVyKG16/Sx zUw4FiI9p1HRomeh18jQpiSB3kpM7jK+eSeigRFjAkyhnk4Wxr0q+JLTX2zdFFd3 DiVUG9y1FpxrWD8oXuQUd2iFulc3Nq7gVYwNnvzChmr/HIMFdPnSPQhLdETW5AZp CZx/oZXP3gHVLF9fovkgh4K5hTB5ME52FX7Moks0f/teOisjbuQ28NJofCFxSUEx UlQiCfB2QAdSYNs6uW+aWh7kBLxJyu3wo5sOoz+pm7ROB2W+gQIlFiKteI0aMINB 75urVZLCE81pPB9qH4HCYghhtvmAGk1XhcXctDlXSrGXJwy9GNglMq/NOc0qLv7+ xHcGBYuNChvbQtwCR6dF2OMij/bsflokWP2HngZDuC9Bihd6wutn1Hr1W0S22L2M xpTKUfs85ms42AVDAhQ/WZ/sbfSbMuODwQJanHszz19XWR6NhZ8H2srEEjwbZySE 9+EDd4252kVkEFMG+HKTCdYCTchJ+2/F78OID+UJAtLsw3WTClo4S6r5Ejwe5xwP AIHfSdyrIFMQNjMIY30G =JbzA -----END PGP SIGNATURE----- --gKMricLos+KVdGMg--