From owner-svn-src-head@FreeBSD.ORG Thu Sep 3 16:08:13 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 761D11065670; Thu, 3 Sep 2009 16:08:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 91A248FC22; Thu, 3 Sep 2009 16:08:12 +0000 (UTC) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 253373209; Thu, 03 Sep 2009 19:08:09 +0300 Message-ID: <4A9FE9E2.1060205@FreeBSD.org> Date: Thu, 03 Sep 2009 19:08:02 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Scott Long References: <200909031237.n83CbIgk032551@svn.freebsd.org> <1872D962-9297-4C45-9F73-4BB823C49D74@samsco.org> <4A9FD8B4.2080605@FreeBSD.org> <20090903095224.N20031@pooker.samsco.org> In-Reply-To: <20090903095224.N20031@pooker.samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r196777 - head/sys/dev/ahci X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:08:13 -0000 Scott Long wrote: > On Thu, 3 Sep 2009, Alexander Motin wrote: >> Scott Long wrote: >>> In this case, set maxio to 64k, not 127.5k. You'll typically get >>> much better i/o performance out of two 64k transfers >>> than you will out of one 127.k transfer and one 512 bytes transfer, >>> which is what the block layer will give you if >>> you try to send 128k. >> >> Couldn't it be somehow handled on that level? > > It's a limitation of the paticular hardware, not the OS. Plain disks > will behave like this, but RAID controllers might now. But if you want > to add this feature to the upper layers, be my guest. Huh. May be sometimes later. >> Limiting maxio from 127.5K to 64K is also a penalty for requests with >> length in that range. > > Most I/O that goes to a disk comes from one of the VM pagers, and is > thus page aligned and multi-of-page sized. Breaking one of these > requests up into sub-page sized requests costs a whole lot more than > what you are assuming. We analyzed exactly this situation a few years > ago at Yahoo and came to this conclusion. Sure, 127.5K is ugly, but what's about 96K or 112K? Is there benefits having it strictly in power of 2? -- Alexander Motin