On Sun, Jul 22 2007, Rik van Riel wrote: > Jens Axboe wrote: > >> I just wish you had a rationale behind them, I don't think it's that >> great of a series. I agree with the low point of 128k. Then it'd be sane >> to try and determine what the upper limit of ra window size goodness is, >> which is probably impossible since it depends on the hardware a lot. But >> lets just say the upper value is 2mb, then I think it's pretty silly >> _not_ to use 2mb on a 1g machine for instance. So more aggressive >> scaling. > > 1 or 2 MB is a nice number. > > Seek time (plus rotational latency) on disks still takes > on the order of 10 ms, while disks commonly transfer data > on the order of 50MB/second. > > That means one disk seek (10ms) takes as long as it takes > to read around 512kB of data. > > The current 128kB means that if you have lots of streaming > IO going on, you spend only 20% of the time transferring > data and get roughly 10MB/s. Seek 10ms, read 2.5ms worth > of data. > > OTOH, if you do 2MB per request for the same heavy streaming > workload (say, an ftp or nfs server doing media files), you > can get 80% of the disk throughput, or 40MB/s. This is because > you spend 40ms transferring data for every 10ms seek time. > > Yes, filesystem metadata will reduce this "occasionally", > but the general idea holds.
I meant real numbers, the above is just rudimentary math. AS and CFQ makes sure that you get a window of more than one request in, so huge read-ahead sizes aren't as interesting. So - more testing, less hand waving :-) -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/