From owner-svn-src-head@FreeBSD.ORG Thu Sep 3 16:17:53 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 5B6BA106566C; Thu, 3 Sep 2009 16:17:53 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0E42F8FC19; Thu, 3 Sep 2009 16:17:52 +0000 (UTC) Received: from pooker.samsco.home (pooker.samsco.home [192.168.254.1]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n83GHkg1088977; Thu, 3 Sep 2009 10:17:46 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Thu, 3 Sep 2009 10:17:46 -0600 (MDT) From: Scott Long To: Alexander Motin In-Reply-To: <4A9FE9E2.1060205@FreeBSD.org> Message-ID: <20090903101015.P20031@pooker.samsco.org> References: <200909031237.n83CbIgk032551@svn.freebsd.org> <1872D962-9297-4C45-9F73-4BB823C49D74@samsco.org> <4A9FD8B4.2080605@FreeBSD.org> <20090903095224.N20031@pooker.samsco.org> <4A9FE9E2.1060205@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org 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:17:53 -0000 On Thu, 3 Sep 2009, Alexander Motin wrote: > 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 > it strictly in power of 2? It's convenient. We've analyzed the combinations. I'm just trying to offer some advice from experience. I'm going to drop the conversation now. Scott