On 2012-01-24, at 9:56, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, Jan 24, 2012 at 10:15:04AM -0500, Chris Mason wrote: >> 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-- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
