From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bD9t1-0005K0-AW for qemu-devel@nongnu.org; Wed, 15 Jun 2016 08:25:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bD9sy-0004u6-Vf for qemu-devel@nongnu.org; Wed, 15 Jun 2016 08:25:34 -0400 References: <1465917916-22348-1-git-send-email-den@openvz.org> <1465917916-22348-4-git-send-email-den@openvz.org> <5760BF45.9020707@redhat.com> <576114A7.4000403@openvz.org> From: Eric Blake Message-ID: <57614935.2030207@redhat.com> Date: Wed, 15 Jun 2016 06:25:25 -0600 MIME-Version: 1.0 In-Reply-To: <576114A7.4000403@openvz.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8IVo0eK2s5Rt7PmXKC1SM0nNtxALxsgwd" Subject: Re: [Qemu-devel] [PATCH 3/9] mirror: optimize dirty bitmap filling in mirror_run a bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" , qemu-devel@nongnu.org, qemu-block@nongnu.org Cc: vsementsov@virtuozzo.com, Stefan Hajnoczi , Fam Zheng , Kevin Wolf , Max Reitz , Jeff Cody This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8IVo0eK2s5Rt7PmXKC1SM0nNtxALxsgwd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/15/2016 02:41 AM, Denis V. Lunev wrote: > On 06/15/2016 05:36 AM, Eric Blake wrote: >> On 06/14/2016 09:25 AM, Denis V. Lunev wrote: >>> There is no need to scan allocation tables if we have mark_all_dirty >>> flag >>> set. Just mark it all dirty. >>> >>> int ret, n; >>> end =3D s->bdev_length / BDRV_SECTOR_SIZE; >>> + if (base =3D=3D NULL && !bdrv_has_zero_init(target_bs)) { >>> + bdrv_set_dirty_bitmap(s->dirty_bitmap, 0, end); >> Won't work as written. 'end' is 64 bits, but bdrv_set_dirty_bitmap() = is >> limited to a 32-bit sector count. Might be first worth updating >> bdrv_set_dirty_bitmap() and friends to be byte-based rather than >> sector-based (but still tracking a sector per bit, obviously), as well= >> as expand it to operate on 64-bit sizes rather than 32-bit. > very nice catch! thank you >=20 [meta-comment - your reply style is a bit hard to read. It's best to include a blank line both before and after any text you write when replying in context, as the extra spacing calls visual attention to your reply rather than being part of a wall of text] >> I'm also worried slightly that the existing code repeated things in a >> loop, and therefore had pause points every iteration and could thus >> remain responsive to an early cancel. But doing the entire operation = in >> one chunk (assuming you fix bitmap code to handle a 64-bit size) may e= nd >> up running for so long without interruption that you lose the benefits= >> of an early interruption that you have by virtue of a 32-bit limit. >> > I do not think that this should be worried actually. We just perform me= mset > inside for not that big area (1 Tb disk will have 2 Mb dirty area > bitmap) under > default parameters. >=20 Okay, so the real slowdown in the loop was the rest of the code (checking backing status in bdrv_is_allocated_above() and not in actually writing to the bitmap (bdrv_set_dirty_bitmap()). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --8IVo0eK2s5Rt7PmXKC1SM0nNtxALxsgwd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXYUk1AAoJEKeha0olJ0Nq+HUIAJA2VNx0BJ4NpwKCXC1sUiW9 W/ZxyfZHWL3d2tjlhzLpbmUtt7SyaJLFdEoo/Mxd+jA+eMxHebJs3f86pibbkv4X q+Pds3tj9QFpJtzE3DoKcvqyaFEjyc2qkIEt4KUDozgHGx4n/ctuoEP0ZAhdwcwJ ajSrFmeBvltezKFCKuYds63mlH7Ij1ackWUd4fv+ndHzNoaei9tF3iz1W7eG7IPS 9p0H3BYOmUNXf0hjq5BYblfK8xkpMPPlzNgEKSPvHlulYgVMjS0OE9LQFZbWYAYj 0UXBautqJkCzD/1uVL77q0iBMIp/MTSh6SLgTag7giTJRKJ+YbsB4nn7dELVZMk= =rpJK -----END PGP SIGNATURE----- --8IVo0eK2s5Rt7PmXKC1SM0nNtxALxsgwd--