From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR1eN-0003IV-Ju for qemu-devel@nongnu.org; Mon, 08 Sep 2014 12:18:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XR1eD-0005lc-Oc for qemu-devel@nongnu.org; Mon, 08 Sep 2014 12:18:43 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:53053 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR1eD-0005lB-Do for qemu-devel@nongnu.org; Mon, 08 Sep 2014 12:18:33 -0400 References: <1409935888-18552-1-git-send-email-pl@kamp.de> <1409935888-18552-3-git-send-email-pl@kamp.de> <20140908134434.GB22582@irqsave.net> <540DB3E2.6010905@redhat.com> <540DB583.4030101@kamp.de> <540DB5EB.2070705@redhat.com> <540DBEBD.9040701@kamp.de> <540DC059.4000907@redhat.com> <540DC7FB.1040804@redhat.com> <540DC8D7.80905@kamp.de> <540DCAE8.4060701@redhat.com> Mime-Version: 1.0 (1.0) In-Reply-To: <540DCAE8.4060701@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <29A6ECA0-C6CE-4557-80CA-31FD2CA199A2@kamp.de> From: Peter Lieven Date: Mon, 8 Sep 2014 18:18:26 +0200 Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: =?utf-8?Q?Beno=C3=AEt_Canet?= , Kevin Wolf , ronnie sahlberg , qemu-devel , Max Reitz , Stefan Hajnoczi > Am 08.09.2014 um 17:27 schrieb Paolo Bonzini : >=20 > Il 08/09/2014 17:18, Peter Lieven ha scritto: >>>=20 >>> That's why we have splitting code for discard, and why we would have to >>> add it for read/write too. >>=20 >> Why should a guest generate such big requests. >=20 > When copying data, gparted will try using very large I/O sizes. Of > course if something breaks it will just use a smaller size, but it would > make performance worse. >=20 > I tried now (with local storage, not virtual---but with such large block > sizes it's disk bound anyway, one request can take 0.1 seconds to > execute) and a 2 MB block size is 20% slower than 16 MB block size on > your usual 3.5" rotational SATA disk. >=20 can you share with what command exactly you ran these tests? i tried myself and found that without multiwrite_merge i was not able to cre= ate a request bigger than 0xffff sectors from inside linux. Peter > Paolo >=20 >> Afaik the reported >> limit for e.g. virtio-blk is 1024 sectors (reported through blockdev >> --getmaxsect /dev/vda). >> I think it was only the multiwrite_merge code causing trouble here. >=20 >=20