From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031261AbXDZP3O (ORCPT ); Thu, 26 Apr 2007 11:29:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1031276AbXDZP3O (ORCPT ); Thu, 26 Apr 2007 11:29:14 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:41420 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1031261AbXDZP3N (ORCPT ); Thu, 26 Apr 2007 11:29:13 -0400 Date: Fri, 27 Apr 2007 01:28:51 +1000 From: David Chinner To: Nick Piggin Cc: Andy Whitcroft , Christoph Lameter , "Eric W. Biederman" , linux-kernel@vger.kernel.org, Mel Gorman , William Lee Irwin III , David Chinner , Jens Axboe , Badari Pulavarty , Maxim Levitsky Subject: Re: [00/17] Large Blocksize Support V3 Message-ID: <20070426152851.GY65285596@melbourne.sgi.com> References: <46303A98.9000605@yahoo.com.au> <46304C74.9040304@yahoo.com.au> <46305177.7060102@yahoo.com.au> <463057D9.9030804@yahoo.com.au> <46309D16.70109@shadowen.org> <4630C061.10309@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4630C061.10309@yahoo.com.au> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2007 at 01:08:17AM +1000, Nick Piggin wrote: > Andy Whitcroft wrote: > >Nick Piggin wrote: > > > > >>I don't understand what you mean at all. A block has always been a > >>contiguous area of disk. > > > > > >Lets take Nick's definition of block being a disk based unit for the > >moment. That does not change the key contention here, that even with > >hardware specifically designed to handle 4k pages that hardware handles > >larger contigious areas more efficiently. David Chinner gives us > >figures showing major overall throughput improvements from (I assume) > >shorter scatter gather lists and better tag utilisation. I am loath to > >say we can just blame the hardware vendors for poor design. > > So their controllers get double the throughput when going from 512K > (128x4K pages) to 2MB (128x16K pages) requests. Do you really think > it is to do with command processing overhead? No - it has to do with things like the RAID controller caching behaviour, the number of disks a single request can keep busy, getting I/os large enough to avoid partial stripe writes, etc. Remember that this controller is often on the other side of a HBA so large I/Os are really desirable here.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group