From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLWpP-0001uo-SF for qemu-devel@nongnu.org; Fri, 08 Jul 2016 10:32:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLWpK-0004eo-Ln for qemu-devel@nongnu.org; Fri, 08 Jul 2016 10:32:26 -0400 References: <1466465969-25315-1-git-send-email-eblake@redhat.com> <1466465969-25315-4-git-send-email-eblake@redhat.com> <20160708110519.GK14684@noname.redhat.com> From: Eric Blake Message-ID: <577FB96E.80607@redhat.com> Date: Fri, 8 Jul 2016 08:32:14 -0600 MIME-Version: 1.0 In-Reply-To: <20160708110519.GK14684@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UVfpUkPu891O4hr1fBt8984lHkgc6XU9s" Subject: Re: [Qemu-devel] [PATCH 3/5] raw_bsd: Don't advertise flags not supported by protocol layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UVfpUkPu891O4hr1fBt8984lHkgc6XU9s From: Eric Blake To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Message-ID: <577FB96E.80607@redhat.com> Subject: Re: [PATCH 3/5] raw_bsd: Don't advertise flags not supported by protocol layer References: <1466465969-25315-1-git-send-email-eblake@redhat.com> <1466465969-25315-4-git-send-email-eblake@redhat.com> <20160708110519.GK14684@noname.redhat.com> In-Reply-To: <20160708110519.GK14684@noname.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/08/2016 05:05 AM, Kevin Wolf wrote: > Am 21.06.2016 um 01:39 hat Eric Blake geschrieben: >> The raw format layer supports all flags via passthrough - but >> it only makes sense to pass through flags that the lower layer >> actually supports. >> >> Thanks to the previous patch, the raw format layer now attempts >> to fragment writes at the max_transfer limit it inherits from >> the NBD protocol layer, recently set to 32m. An attempt to do >> 'w -f 0 40m' to an NBD server that lacks FUA thus changed from >> flushing once (after NBD fragmented a single 40m write itself) >> to instead flushing twice (the format layer sees BDRV_REQ_FUA >> in supported_write_flags, so it sends the flag on to both >> fragments, and then the block layer emulates FUA by flushing >> for both the 32m and 8m fragments at the protocol layer). >> This patch fixes the performance regression (now that the >> format layer no longer advertises a flag not present at the >> protocol layer, the flush to emulate FUA is deferred to the >> last fragment). >> >> Note that 'w -f -z 0 40m' does not currently exhibit the same >> problem, because there, the fragmentation does not occur until >> at the NBD layer (the raw layer has .bdrv_co_pwrite_zeroes, and >> the NBD layer doesn't advertise max_pwrite_zeroes to constrain >> things at the raw layer) - but that problem is latent and would >> have the same problem with too many flushes without this patch >> once the NBD layer implements support for using the new >> NBD_CMD_WRITE_ZEROES and sets max_pwrite_zeroes to the same 32m >> limit as recommended by the NBD protocol. >> >> Signed-off-by: Eric Blake >=20 > Should this be moved before patch 2 so that we never get a regression i= n > the first place? Can do, although it will require some word-smithing to the commit message= =2E --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --UVfpUkPu891O4hr1fBt8984lHkgc6XU9s 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/ iQEcBAEBCAAGBQJXf7lvAAoJEKeha0olJ0Nq7l8IAI2iakIjqLaNOrKmxaUcJ30D VfXb0r5T8A2eVusZz6cneJm6R5mKT8yRuvL451wfPtPm9RqStEbv+PGeWnLNCKDx iRTacTo3RHC+LZUmU4XBXK9l5+5EPaYFHL28sC+S2UBZFYVBu0DdakuS/Fvd9RqK d1027a6UHMI1ubPWcmHRrWXYzJm20xLWMzWjsRUhF3BGE0rDGgKE/F6tayjQqLqG se7dm4vajRK+slQvJsAqqKqZM5nmrGpXP6s0q+SBSVYhdAoH12qAc14uBReXUddo tSn0moIxEno/rrD+j6HFNgt7S87guiWt3B32kucEQow2MhsH3h7kAPTLK0qs6+o= =rxsA -----END PGP SIGNATURE----- --UVfpUkPu891O4hr1fBt8984lHkgc6XU9s--