From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCaX7-0000uf-KB for qemu-devel@nongnu.org; Wed, 30 Jul 2014 16:31:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCaX1-0003Uy-T0 for qemu-devel@nongnu.org; Wed, 30 Jul 2014 16:31:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCaX1-0003RJ-L1 for qemu-devel@nongnu.org; Wed, 30 Jul 2014 16:31:27 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6UKVQMp019292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 30 Jul 2014 16:31:26 -0400 Message-ID: <53D9561D.5010505@redhat.com> Date: Wed, 30 Jul 2014 14:31:25 -0600 From: Eric Blake MIME-Version: 1.0 References: <1406311665-2814-1-git-send-email-mreitz@redhat.com> <1406311665-2814-8-git-send-email-mreitz@redhat.com> <53D919CC.9050706@redhat.com> In-Reply-To: <53D919CC.9050706@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Cw6VgAnhEtXIbvhpi0Pt0Omlp1JUvaVCp" Subject: Re: [Qemu-devel] [PATCH 7/8] block/qcow2: Speed up zero cluster expansion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cw6VgAnhEtXIbvhpi0Pt0Omlp1JUvaVCp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/30/2014 10:14 AM, Eric Blake wrote: > On 07/25/2014 12:07 PM, Max Reitz wrote: >> Actually, we do not need to allocate a new data cluster for every zero= >> cluster to be expanded: It is completely sufficient to rely on qcow2's= >> COW part and instead create a single zero cluster and reuse it as much= >> as possible. > Also, I have to wonder - since the all-zero cluster is the most likely > cluster to have a large refcount, even during normal runtime, should we= > special case the normal qcow2 write code to track the current all-zero > cluster (if any), and merely increase its refcount rather than allocate= > a new cluster any time it is detected that an all-zero cluster is > needed? [Of course, the tracking would be runtime only, since > compat=3D0.10 header doesn't provide any way to track the location of a= n > all-zero cluster across file reloads. Each new runtime would probably > settle on a new location for the all-zero cluster used during that run,= > rather than trying to find an existing one. And there's really no poin= t > to adding a header to track an all-zero cluster in compat=3D1.1 images,= > since those images already have the ability to track zero clusters > without needing one allocated.] >> + ret =3D bdrv_write_zeroes(bs->file, offset / BDRV= _SECTOR_SIZE, >> + s->cluster_sectors, 0); >=20 > That is, if bdrv_write_zeroes knows how to take advantage of an already= > existing all-zero cluster, it would be less special casing in this code= , > but still get the same benefits of maximizing refcount during the amend= > operation, if all expanded clusters go through bdrv_write_zeroes. Now that I've looked through both variants, I'm leaning towards the simplicity of your alternate series, rather than the complexity of this one, if we can (independently?) optimize bdrv_write_zeroes to reuse a known-all-zeroes cluster when possible. Of course, you may want to get other opinions than just mine before posting your next round of these patches. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Cw6VgAnhEtXIbvhpi0Pt0Omlp1JUvaVCp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT2VYdAAoJEKeha0olJ0Nqv2MH/jbB9RXHswSNiRnPiv4i76EV g9RcZ1jYd4o1Gq8edISfuX98+lXViK9Idsvr7FJogev8eUNCZMvuY/87aHRrLmyC R3sIAa/09S9YPDoYRqvryLU7Vk1sVvMy5DYMmuSYMkPVCfHeqgvmywa/vdOB+kga w73NVDi67wWjlSkPO8bNYtnw1SU3quKJ05OUrilCkttkIe49qAk58aV8R6c5BzcH eX9hZpEkRiRhyicExTfodhrPlrZeyKCCPeezODy0Bi6KCFdA9r0IfJQ1lf4sw5K9 dT1qF+Xk4fXjvRxKI46usUq/9bY1n4YJfrB2yl2ySlEVKhDxSOaoAob6kALP6f0= =BPhB -----END PGP SIGNATURE----- --Cw6VgAnhEtXIbvhpi0Pt0Omlp1JUvaVCp--