From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR0rM-0002zR-Dy for qemu-devel@nongnu.org; Mon, 08 Sep 2014 11:28:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XR0rC-0000ZC-FU for qemu-devel@nongnu.org; Mon, 08 Sep 2014 11:28:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR0rC-0000XL-8c for qemu-devel@nongnu.org; Mon, 08 Sep 2014 11:27:54 -0400 Message-ID: <540DCAE8.4060701@redhat.com> Date: Mon, 08 Sep 2014 17:27:36 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <540DC8D7.80905@kamp.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Peter Lieven , ronnie sahlberg Cc: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , Kevin Wolf , qemu-devel , Stefan Hajnoczi , Max Reitz Il 08/09/2014 17:18, Peter Lieven ha scritto: >> >> That's why we have splitting code for discard, and why we would have to >> add it for read/write too. > > Why should a guest generate such big requests. 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. 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. Paolo > 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.