Re: [PATCH 3/3] readahead: scale max readahead size depending on memory size

[Jens Axboe <jens.axboe@oracle.com>]

On Sun, Jul 22 2007, Peter Zijlstra wrote:
> On Sun, 2007-07-22 at 10:24 +0200, Jens Axboe wrote:
> > On Sat, Jul 21 2007, Peter Zijlstra wrote:
> 
> > > +static __init int readahead_init(void)
> > > +{
> > > +	/*
> > > +	 * Scale the max readahead window with system memory
> > > +	 *
> > > +	 *   64M:   128K
> > > +	 *  128M:   180K
> > > +	 *  256M:   256K
> > > +	 *  512M:   360K
> > > +	 *    1G:   512K
> > > +	 *    2G:   724K
> > > +	 *    4G:  1024K
> > > +	 *    8G:  1448K
> > > +	 *   16G:  2048K
> > > +	 */
> > > +	ra_pages = int_sqrt(totalram_pages/16);
> > > +	if (ra_pages > (2 << (20 - PAGE_SHIFT)))
> > > +		ra_pages = 2 << (20 - PAGE_SHIFT);
> > > +
> > > +	return 0;
> > > +}
> > 
> > How did you come up with these numbers?
> 
> Well, most other places in the kernel where we scale by memory size we
> use the a sqrt curve, and the specific scale was the result of some
> fiddling, these numbers looked sane to me, nothing special.
> 
> Would you suggest a different set, and if so, do you have any rationale
> for them?

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.

Then there's the relationship between nr of requests and ra size. When
you leave everything up to a simple sqrt of total_ram type thing, then
you are sure to hit stupid values that cause a queue size of a number of
full requests, plus a small one at the end. Clearly not optimal!

-- 
Jens Axboe