On 01/26/2012 12:46 AM, Andrea Arcangeli wrote: > On Wed, Jan 25, 2012 at 03:06:13PM -0500, Chris Mason wrote: >> We can talk about scaling up how big the RA windows get on their own, >> but if userland asks for 1MB, we don't have to worry about futile RA, we >> just have to make sure we don't oom the box trying to honor 1MB reads >> from 5000 different procs. > > :) that's for sure if read has a 1M buffer as destination. However > even cp /dev/sda reads/writes through a 32kb buffer, so it's not so > common to read in 1m buffers. > That's not so true. cp is a bad example because it's brain dead and someone should fix it. cp performance is terrible. Even KDE's GUI copy is better. But applications (and dd users) that do care about read performance do use large buffers and want the Kernel to not ignore that. What a better hint for Kernel is the read() destination buffer size. > But I also would prefer to stay on the simple side (on a side note we > run out of page flags already on 32bit I think as I had to nuke > PG_buddy already). > So what would be more simple then not ignoring read() request size from application, which will give applications all the control they need. <snip> (I Agree) > The config option is also ok with me, but I think it'd be nicer to set > it at boot depending on ram size (one less option to configure > manually and zero overhead). If you actually take into account the destination buffer size, you'll see that the read-ahead size becomes less important for these workloads that actually care. But Yes some mount time heuristics could be nice, depending on DEV size and MEM size. For example in my file-system with self registered BDI I set readhead sizes according to raid-strip sizes and such so to get good read performance. And speaking of reads and readhead. What about alignments? both of offset and length? though in reads it's not so important. One thing some people have ask for is raid-verify-reads as a mount option. Thanks Boaz -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
