From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJkZS-0007cP-Gk for qemu-devel@nongnu.org; Tue, 19 Aug 2014 10:39:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJkZL-0000v1-Uf for qemu-devel@nongnu.org; Tue, 19 Aug 2014 10:39:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJkZL-0000uo-LC for qemu-devel@nongnu.org; Tue, 19 Aug 2014 10:39:27 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7JEdQDR006148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Aug 2014 10:39:26 -0400 Date: Tue, 19 Aug 2014 16:39:22 +0200 From: Kevin Wolf Message-ID: <20140819143922.GI4638@noname.redhat.com> References: <1408392454-22044-1-git-send-email-mreitz@redhat.com> <20140819140049.GG4638@noname.redhat.com> <53F35CC7.1040909@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline In-Reply-To: <53F35CC7.1040909@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/4] qcow2: Allow runtime specification of cache sizes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 19.08.2014 um 16:18 hat Eric Blake geschrieben: > On 08/19/2014 08:00 AM, Kevin Wolf wrote: > > Am 18.08.2014 um 22:07 hat Max Reitz geschrieben: > >> Currently, the metadata cache size is only tunable on compile time > >> through macros. However, some users may want to use the minimal cache > >> size (for whatever reason) and others may want to increase the cache > >> size because they have enough memory and want to increase performance. > >> > >> This series adds runtime options for setting the cache size in bytes > >> (which is an easily comprehensible unit) in various ways (by setting > >> each cache explicitly or the total size). > >> > >> > >> This series (patch 2) depends on Markus' series > >> "[PATCH v2 0/4] block: Use g_new() & friends more". > >> > >> > >> v2: > >> - Patch 2: c->entries may be NULL in the fail path; respect that case > >=20 > > Thanks, applied all to the block branch (with patch 1 changed as > > commented there). >=20 > I'd still like to see the changes to qapi/block-core.json that expose > these for hot-plugging before we call this series finished (I mentioned > that in my review of v1, without realizing that v2 had already been sent). Yes, we need this. But Max replied there that he'd send a follow-up and that was good enough for me because my experience is that he is one of the few people who don't only promise follow-up patches, but actually send them. Kevin --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJT82GaAAoJEH8JsnLIjy/WcG8P/0WP7perYjQknt2Wu8ADW7fG 2htxFhXrWWQshG11Us2vSt+wf04RMlUycDVEKJowYqfWpxuG613dERqkjQDycgyd GDRAGtwfe9SDxnvjPbFxbXXTHLYY59V3H+5vhnxZZTWWX80QtnlQ8dPRNJmBpjff gN2P5iN9MyxTrWz1+WXfMA8oO+WCfrNvfcczaLBtUz75oAb470m7SR6HR7jj3YLf R66/zht/gkP6BwhpwLwg4txawe+OzryA9AQg97DTaryNEhp9HepExaXVoyTbvq6U QufxFsA+H0fL1Pf51NggaQ9vNnvaA2QW5nZM6yWL5IROM9A1GVHvx75BBC2ncFEe BLwTiRbIIGa85/fFMVhKPSgL4ktSQ/kuQiNc8q+mskJyjdlqSsOup2w25zgFjgLZ RbfS+BWfKUcLmmWJLHLJQIoj8BT1JJo1Y1FSWcyPA79jVOuSIBy4BMBg9R0STRXw ef79B5y+7f1taSo0x8D5CQrTIlkezzLZyWmTKCDJxv7/t6DPhRs85ClUEwoaK6+x WAbUaF/jQn3B7uXi3JAXKjBNKh4uJ1GDsvjKTfrHwZWEINsJ9R38XZEpayuhiMKD dSAbQj/7OX0l9pmChO+YxXNhhu9pnObWz31WBiYWJVwmhc1ko3qPVBrq0sgo5eLj azn4D6q1D0A8l3AblALP =E4Hn -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/--