From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQFeT-0004Kd-P3 for qemu-devel@nongnu.org; Thu, 21 Jul 2016 11:12:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQFeP-0005nJ-ER for qemu-devel@nongnu.org; Thu, 21 Jul 2016 11:12:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQFeP-0005nE-5P for qemu-devel@nongnu.org; Thu, 21 Jul 2016 11:12:37 -0400 References: <577A6955.6020603@kamp.de> <57900AB3.3040705@redhat.com> <0da28a84-5b9a-ac8c-0bd8-e03cfc824bcb@redhat.com> From: Eric Blake Message-ID: <5790E65E.6040605@redhat.com> Date: Thu, 21 Jul 2016 09:12:30 -0600 MIME-Version: 1.0 In-Reply-To: <0da28a84-5b9a-ac8c-0bd8-e03cfc824bcb@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6hMW5Xax0sGEb7TSqKwaPk0K6lPvbiX9G" 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) --6hMW5Xax0sGEb7TSqKwaPk0K6lPvbiX9G From: Eric Blake To: Paolo Bonzini , Peter Lieven , "qemu-devel@nongnu.org" Cc: Kevin Wolf Message-ID: <5790E65E.6040605@redhat.com> Subject: Re: Regression: block: Add .bdrv_co_pwrite_zeroes() References: <577A6955.6020603@kamp.de> <57900AB3.3040705@redhat.com> <0da28a84-5b9a-ac8c-0bd8-e03cfc824bcb@redhat.com> In-Reply-To: <0da28a84-5b9a-ac8c-0bd8-e03cfc824bcb@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/21/2016 03:08 AM, Paolo Bonzini wrote: >=20 >=20 > On 21/07/2016 01:35, Eric Blake wrote: >> Also, while the device is advertising that the optimal discard alignme= nt >> is 15M, that does not tell me the minimum granularity that it can >> actually discard. Can you determine that value? That is, if I try to= >> discard only 1M, does that actually result in a 1M allocation hole, or= >> is it ignored? It sounds like qemu should be tracking 2 separate >> values: the minimum discard granularity (I suspect this number is a >> power of 2, at least the block size, and perhaps precisely equal to th= e >> block size) >=20 > It's very unlikely to be equal to the block size. The block size is > probably 512, perhaps 4096, while the optimal discard alignment is > usually at least 64K. It would be nice to determine what the true minimum is, whether it is a block size, or 64k, or some other number. >=20 >> Or put another way, I get that I can't discard more than 15M at a time= =2E >=20 > I don't think so; optimal discard alignment is 15M but maximum discard > size is most likely _not_ 15M. Peter proved that the device itself reports that its optimal size and maximum size are equal, at 15M each. >=20 >> Optimal size not being a power of 2 is not a problem, but I still >> suspect MINIMUM alignment is a power of 2, and I need to know how much= >> head and tail to discard in the new byte-based discard routines in ord= er >> to align requests up to the minimal discard alignment boundaries. >=20 > But why does it matter if it is a power of 2? Can't you just use > DIV_ROUND_UP? Oddly enough, ROUND_UP() requires a power of 2, but is otherwise identical to QEMU_ALIGN_UP() which does not require a power of 2. DIV_ROUND_UP() scales down, so I'd have to scale back up, basically open-coding QEMU_ALIGN_UP() which keeps the scale unchanged. I'm seriously debating about adding comments to osdep.h on which macros require a power of 2 or not, and/or a cleanup patch that unifies ROUND_UP() and QEMU_ALIGN_UP() to be the same functionality (since they are already the same for power of 2). A decent compiler should be able to optimize * and / back into bit twiddling if it knows that the rounding amount is a power of 2. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --6hMW5Xax0sGEb7TSqKwaPk0K6lPvbiX9G 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/ iQEcBAEBCAAGBQJXkOZeAAoJEKeha0olJ0NqEFcH/jY9QEJl75qDw+fHQ/PQ0Py8 pLQ2T74O/G6K5LBvfJyRvZMe7L1HoN2lkx0/6X+EzlohzgIoG9UgIdx04esOsH9w lPtayl/a7v/Wl0aDyh0ZJ29eH0mruUjgaeIEWecwzgvcpcNCCeFIs6/esZbxHf1h VTLsMjpvKkVy1qXb37h+MhZnCRI1aBlNEehRDHTDq8LPLcGXCeN0deLMpjAcszkl Dv4xWVdMTXuoI9IUblI0Ct8AdPM76Lvc5NWjqwuyrask5zUU5IcI5Pst6RCgs9js 7ytiIgoMt25ej6BrWh6L8xx9NLCMRHYAA/DRAleDGJYn46PGq46G/UR3wJVSdoI= =lqOq -----END PGP SIGNATURE----- --6hMW5Xax0sGEb7TSqKwaPk0K6lPvbiX9G--