From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKRob-0004wV-5e for qemu-devel@nongnu.org; Tue, 05 Jul 2016 10:59:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKRoV-0002DB-ND for qemu-devel@nongnu.org; Tue, 05 Jul 2016 10:59:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKRoV-0002D4-EC for qemu-devel@nongnu.org; Tue, 05 Jul 2016 10:59:03 -0400 References: <577A6955.6020603@kamp.de> <577B130A.3040205@redhat.com> <3221d3d3-37ee-9752-396e-379792445ee0@redhat.com> From: Eric Blake Message-ID: <577BCB35.6060103@redhat.com> Date: Tue, 5 Jul 2016 08:59:01 -0600 MIME-Version: 1.0 In-Reply-To: <3221d3d3-37ee-9752-396e-379792445ee0@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2KE7CUkJNrJwQbMdIJPIvveDlcfLqkWVb" Subject: Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Peter Lieven , "qemu-devel@nongnu.org" Cc: Kevin Wolf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2KE7CUkJNrJwQbMdIJPIvveDlcfLqkWVb From: Eric Blake To: Paolo Bonzini , Peter Lieven , "qemu-devel@nongnu.org" Cc: Kevin Wolf Message-ID: <577BCB35.6060103@redhat.com> Subject: Re: Regression: block: Add .bdrv_co_pwrite_zeroes() References: <577A6955.6020603@kamp.de> <577B130A.3040205@redhat.com> <3221d3d3-37ee-9752-396e-379792445ee0@redhat.com> In-Reply-To: <3221d3d3-37ee-9752-396e-379792445ee0@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/05/2016 07:37 AM, Paolo Bonzini wrote: >=20 >=20 > On 05/07/2016 03:53, Eric Blake wrote: >>>> I think we cannot assert that that these alignments are a power of 2= =2E >> Perhaps that means we should just fix our code to round things down to= >> the nearest power of 2 (8MB) for the opt_transfer_len and >> opt_discard_alignment values. Can you post a stack-trace of the actua= l >> assertion you are hitting? >=20 > It doesn't work for opt_discard_alignment. Neither 8MB nor 16MB is > aligned to 15MB for example. The largest power-of-2 alignment that will align with every 15M page is 1M. Is there a measurable performance difference between doing lots of 1M accesses (14 out of 15 are unaligned, but none of them cross page boundaries), vs. doing 8M accesses (14 out of 15 are unaligned, and 7 out of 15 cross page boundaries, but there are fewer accesses overall)? The optimal alignments are advisory - they should be a hint that says that accesses smaller than the alignment may require RMW and are therefore slower. I agree that at a certain point, we will definitely see slowdowns (if we do all 64k accesses, we could probably notice it), but I'm having a hard time seeing how hardware that advertises a non-power-of-2 can behave less efficiently for 1M than it would for 8M, particularly if the smallest addressable block size is indeed smaller than 1M on that device. And yes, we could probably switch to (potentially slower) / % * instead of bit operations in block/io.c to accommodate a non-power-of-2 optimal size, but it would require a careful audit to make sure we don't have even more bit-wise operations lurking that were assuming a power of 2. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --2KE7CUkJNrJwQbMdIJPIvveDlcfLqkWVb 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/ iQEcBAEBCAAGBQJXe8s2AAoJEKeha0olJ0NqT4kIAKrodGoae5BNpH0B3DF1RGIR VCXRPeqwHNyJDooYlahnsjv7JEnr3zyoIODwcwHl9QgFRGxaPGDVkMpseb/qgsAJ NgQwOozwoJf/VpsQ+9o5NNnYcqiMvMCKiCxGdOCl+8lO9EqyPFD3ObwKmvyZE0gO 5R/thUbYGHZq3OPzBDW9N5IbNecvC+t42Rh82mBB+z92kyQndnlxAFCvD71QWnio g3v0vZRH2hfE/aH94mrhIBtUYhPgAOxK32K5usioPi/llIcrp1PWnA9M+fhf/lzS dIFxZVRjbPnYVzzB74vtVJbE+0O9mB6/jVGrKvPz7o/TaJj9Jp08wPrOcn75b3k= =2U6f -----END PGP SIGNATURE----- --2KE7CUkJNrJwQbMdIJPIvveDlcfLqkWVb--