From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ykrr6-00038i-Og for qemu-devel@nongnu.org; Wed, 22 Apr 2015 06:26:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ykrr3-0007qf-It for qemu-devel@nongnu.org; Wed, 22 Apr 2015 06:26:08 -0400 Date: Wed, 22 Apr 2015 11:26:02 +0100 From: Stefan Hajnoczi Message-ID: <20150422102602.GA20029@stefanha-thinkpad.redhat.com> References: <1429629639-14328-1-git-send-email-berto@igalia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <1429629639-14328-1-git-send-email-berto@igalia.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: do lazy allocation of the L2 cache List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 21, 2015 at 06:20:39PM +0300, Alberto Garcia wrote: > Large disk images need large L2 caches in order to maximize their > I/O performance. However setting a correct size for the cache is not > necessarily easy since apart from the image size, it also depends > on other factors like its usage patterns or whether it's part of a > backing chain. >=20 > In order to be able to set a very large cache size to cover the > worst-case scenarios and yet prevent an unnecessary waste of memory, > this patch modifies the qcow2 cache algorithm so the memory for each > entry is allocated only when it's actually needed. >=20 > This also improves the scenarios with smaller images: the current > default L2 cache size can map a whole 8GB disk, so those smaller than > that are allocating cache memory that can never be used. What measurable improvement does this patch make? Buffers allocated upfront are not touched, so they don't actually consume physical memory. Stefan --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVN3c6AAoJEJykq7OBq3PIW6gH/jvYJzvtgnC/Rh/TlWXTc1NU E1Z1zxa1rOgphSpOVtZ+B4qevTS66Vz9Pf1zQN79TnL2fGbUOS/ty+Nc3HxZFWEC /5b8w2hpnkoq4Deitc3n2npMR8m3Op1jDqiOT+PPwcK6ieIwGG4eB0Lnls+2AbIY AZccDVRGUIi6s/UCJywbx+ZTFvQHRQZeeJ6HfTHiAOdsSkkQSvfY4K5nos2MZDfJ +g0mMr63IqTKqLRJKhOUWsU9WrWyWIgAkqahkVuni1E/KcaIgFVbUpYBcSfQ2AoF 8xNEwEAgYw80j7lKapcRlK7hwVwXiLHqmIvkzmfSAyJuk/cdMhxQX0p7LeqxUUM= =n27w -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c--