From owner-svn-src-head@FreeBSD.ORG Thu Sep 3 15:59:45 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 F1E321065670; Thu, 3 Sep 2009 15:59:45 +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 8A6268FC0C; Thu, 3 Sep 2009 15:59:45 +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 n83FxfE3088881; Thu, 3 Sep 2009 09:59:41 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Thu, 3 Sep 2009 09:59:41 -0600 (MDT) From: Scott Long To: Alexander Motin In-Reply-To: <4A9FD8B4.2080605@FreeBSD.org> Message-ID: <20090903095224.N20031@pooker.samsco.org> References: <200909031237.n83CbIgk032551@svn.freebsd.org> <1872D962-9297-4C45-9F73-4BB823C49D74@samsco.org> <4A9FD8B4.2080605@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 15:59:46 -0000 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. > 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. > It would be > nice if every level would do it's own job. It's the job of the driver to handle the limitations of the hardware, yes. Again, if you want to experiment with pushing this functionality into GEOM, be my guest. But until then, consider following my advice. Scott > >> On Sep 3, 2009, at 6:37 AM, Alexander Motin wrote: >>> Author: mav >>> Date: Thu Sep 3 12:37:17 2009 >>> New Revision: 196777 >>> URL: http://svn.freebsd.org/changeset/base/196777 >>> >>> Log: >>> ATI SB600 can't handle 256 sectors transfers with FPDMA (NCQ). >>> >>> MFC after: 3 days >>> >>> Modified: >>> head/sys/dev/ahci/ahci.c >>> >>> Modified: head/sys/dev/ahci/ahci.c >>> ============================================================================== >>> --- head/sys/dev/ahci/ahci.c Thu Sep 3 10:06:37 2009 (r196776) >>> +++ head/sys/dev/ahci/ahci.c Thu Sep 3 12:37:17 2009 (r196777) >>> @@ -1942,6 +1942,9 @@ ahciaction(struct cam_sim *sim, union cc >>> cpi->protocol = PROTO_ATA; >>> cpi->protocol_version = PROTO_VERSION_UNSPECIFIED; >>> cpi->maxio = MAXPHYS; >>> + /* ATI SB600 can't handle 256 sectors with FPDMA (NCQ). */ >>> + if (pci_get_devid(device_get_parent(dev)) == 0x43801002) >>> + cpi->maxio = min(cpi->maxio, 255 * 512); >>> cpi->ccb_h.status = CAM_REQ_CMP; >>> xpt_done(ccb); >>> break; >> > > > -- > Alexander Motin >