From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XP9ip-0003gh-SM for qemu-devel@nongnu.org; Wed, 03 Sep 2014 08:31:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XP9ik-0005sV-Ua for qemu-devel@nongnu.org; Wed, 03 Sep 2014 08:31:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XP9ik-0005sQ-LJ for qemu-devel@nongnu.org; Wed, 03 Sep 2014 08:31:30 -0400 Date: Wed, 3 Sep 2014 13:31:17 +0100 From: Stefan Hajnoczi Message-ID: <20140903123117.GJ28095@stefanha-thinkpad.redhat.com> References: <53903469.8070902@msgid.tls.msk.ru> <539FDCAD.5060006@kamp.de> <53A02351.8060900@redhat.com> <53A02867.7090400@kamp.de> <53A02AA6.2060006@redhat.com> <54048EE8.3040305@kamp.de> <54061ADA.7040109@kamp.de> <1AAAA9D6-D7FE-447C-B136-AB3F66F67D35@kamp.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fU0UwhtRbpo05rnG" Content-Disposition: inline In-Reply-To: <1AAAA9D6-D7FE-447C-B136-AB3F66F67D35@kamp.de> Subject: Re: [Qemu-devel] [PATCH] block/iscsi: use 16 byte CDBs only when necessary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , Paolo Bonzini , Michael Tokarev , qemu-devel , ronnie sahlberg --fU0UwhtRbpo05rnG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 03, 2014 at 10:09:21AM +0200, Peter Lieven wrote: >=20 >=20 > > Am 02.09.2014 um 21:30 schrieb Peter Lieven : > >=20 > > Looking at the code, is it possible that not the guest is causing troub= le here, but > > multiwrite_merge code? > >=20 > > From what I see the only limit it has when merging requests is the numb= er of IOVs. > >=20 > >=20 > > Any thoughts? > >=20 > > Mine are: > > a) Introducing bs->bl.max_request_size and set merge =3D 0 if the resul= t would be too big. Default > > max request size to 32768 sectors (see below). > > b) Hardcoding the limit in multiwrite_merge for now limiting the merged= size to 16MB (32768 sectors). > > Which is the limit we already use in bdrv_co_discard and bdrv_co_wr= ite_zeroes if we don't know > > better. >=20 > or c) disabling multiwrite merge for RAW or only iSCSI completely. I think you're right, multiwrite could merge a larger request than the storage device can handle. Do you want to implement a)? b) is okayish. c) is too hacky and might result in performance regressions because it changes the I/O pattern for existing guests. Stefan --fU0UwhtRbpo05rnG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUBwoVAAoJEJykq7OBq3PIvWIIAIIIv0WHnXPjrvDrdXYmu8qD IenuYf8fos/AKbXXK6iBomVz2kNgdMxSkQG+zpRF141KFmBnx1tosdiPZPZ+JUnO fr9rOUBsSckCbroHbYomM7FT1h3O9AGRfjbsePBbuRgYbmSXLYZWkHD0OE2STK6I lsOv5tlMaiqjsKNaIOiuHiXlehuNVcfi1FCixVrOrHtBaVYvAuMiPjwcAq7fJ3Hs Ugze4EI5E2v7i5dHSGnBuITa1gaW6GuVBEIGjHCqyLtECWpWbSS26Ix50XJda+sC 8rcqJiynBQGMNGZQrKGjC9qhIPrij/yBYhmfV87kS7Il/nSNIR++qBXIVpsZL58= =onOq -----END PGP SIGNATURE----- --fU0UwhtRbpo05rnG--