On 2012-01-24, at 9:56, Christoph Hellwig [off-list ref] wrote:

On Tue, Jan 24, 2012 at 10:15:04AM -0500, Chris Mason wrote:

quoted

https://lkml.org/lkml/2011/12/13/326

This patch is another example, although for a slight different reason.
I really have no idea yet what the right answer is in a generic sense,
but you don't need a 512K request to see higher latencies from merging.

That assumes the 512k requests is created by merging.  We have enough
workloads that create large I/O from the get go, and not splitting them
and eventually merging them again would be a big win.  E.g. I'm
currently looking at a distributed block device which uses internal 4MB
chunks, and increasing the maximum request size to that dramatically
increases the read performance.

(sorry about last email, hit send by accident)

I don't think we can have a "one size fits all" policy here. In most RAID devices the IO size needs to be at least 1MB, and with newer devices 4MB gives better performance.

One of the reasons that Lustre used to hack so much around the VFS and VM APIs is exactly to avoid the splitting of read/write requests into pages and then depend on the elevator to reconstruct a good-sized IO out of it.

Things have gotten better with newer kernels, but there is still a ways to go w.r.t. allowing large IO requests to pass unhindered through to disk (or at least as far as enduring that the IO is aligned to the underlying disk geometry). 

Cheers, Andreas