From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsWE6-0004Rf-G4 for qemu-devel@nongnu.org; Tue, 08 Jan 2013 05:16:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsWE5-0007tZ-BD for qemu-devel@nongnu.org; Tue, 08 Jan 2013 05:16:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsWE5-0007tM-34 for qemu-devel@nongnu.org; Tue, 08 Jan 2013 05:16:09 -0500 From: Vadim Rozenfeld Date: Tue, 8 Jan 2013 12:15:59 +0200 References: <24F53AF8-51CF-4A00-9827-86BF38680BDA@dlhnet.de> <201301081129.59373.vrozenfe@redhat.com> <052325BF-3E1A-4565-B0CE-2252EF78F5BA@dlhnet.de> In-Reply-To: <052325BF-3E1A-4565-B0CE-2252EF78F5BA@dlhnet.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301081215.59705.vrozenfe@redhat.com> Subject: Re: [Qemu-devel] Windows and I/O size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: "qemu-devel@nongnu.org" , ronnie sahlberg On Tuesday, January 08, 2013 11:47:54 AM Peter Lieven wrote: > Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld : > > On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote: > >> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld : > >>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote: > >>>> Hi all, > >>>> > >>>> I came across the fact that Windows seems to requests greater 64KB > >>>> into pieces leading to a lot of IOPs on the storage side. > >>>> > >>>> Can anyone imagine of a way to merge them before sending them to e.g. > >>>> an iSCSI Storage? 64KB I/O Size is not optimal when e.g. large > >>>> sequential operations with an iSCSI target. > >>>> > >>>> Thank you, > >>>> Peter > >>> > >>> Hi Peter. > >>> Is it viostor? Which version? The most recent one is able to handle > >>> 256K blocks. > >> > >> Not the recent. I will try 0.1.49 now. > >> > >> 256KB is still not that much but definitely better than 64KB. are this > >> windows limits? > > > > not exactly. it came from the driver itself. actually, with indirect > > buffer support in virtio the sky is the limit. > > would it be possible to make this value user adjustable in the driver > settings? > technically, yes. > I can meanwhile confirm that the IOPS for sequential reads (writes not > tested) have dropped to 1/4 as expected. > > I think 256K is a reasonable value. What was the reason to choose it? In Windows cache manager operates with 256 KB blocks. Cheers, Vadim. > > Thank you, > Peter > > >> I have found docs in the net that windows splits up everything into 64kB > >> requests. Is this info old? > >> > >> thank you, > >> Peter > >> > >>> Best regards, > >>> Vadim.