On Tue, Jan 24, 2012 at 11:56:31AM -0500, Christoph Hellwig 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. Is this read latency or read tput? If you're waiting on the whole 4MB anyway, I'd expect one request to be better for both. But Andrea's original question was on the impact of the big request on other requests being serviced by the drive....there's really not much we can do about that outside of more knobs for the admin. -chris -- 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
