From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR1pc-0006u0-6j for qemu-devel@nongnu.org; Mon, 08 Sep 2014 12:30:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XR1pW-0003jF-1J for qemu-devel@nongnu.org; Mon, 08 Sep 2014 12:30:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR1pV-0003ii-Qu for qemu-devel@nongnu.org; Mon, 08 Sep 2014 12:30:13 -0400 Message-ID: <540DD986.8010301@redhat.com> Date: Mon, 08 Sep 2014 18:29:58 +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> <540DCAE8.4060701@redhat.com> <29A6ECA0-C6CE-4557-80CA-31FD2CA199A2@kamp.de> In-Reply-To: <29A6ECA0-C6CE-4557-80CA-31FD2CA199A2@kamp.de> Content-Type: text/plain; charset=windows-1252 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 Cc: =?windows-1252?Q?Beno=EEt?= =?windows-1252?Q?_Canet?= , Kevin Wolf , ronnie sahlberg , qemu-devel , Max Reitz , Stefan Hajnoczi Il 08/09/2014 18:18, Peter Lieven ha scritto: >> > 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. >> > > 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 create a request bigger than 0xffff sectors from inside linux. On a different machine: $ time dd if=/dev/zero of=test bs=16777216 count=30 oflag=direct real 0m13.497s user 0m0.001s sys 0m0.541s $ time dd if=/dev/zero of=test2 bs=1048576 count=480 oflag=direct real 0m15.835s user 0m0.005s sys 0m0.770s The bigger block size is 17% faster; for disk-to-disk copy: $ time dd if=test of=test3 bs=16777216 count=30 iflag=direct oflag=direct real 0m26.075s user 0m0.001s sys 0m0.678s $ time dd if=test2 of=test4 bs=1048576 count=480 iflag=direct oflag=direct real 0m45.210s user 0m0.005s sys 0m1.145s The bigger block size is 73% faster. Paolo