[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1185093405.20032.205.camel@twins>
Date: Sun, 22 Jul 2007 10:36:45 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Jens Axboe <jens.axboe@...cle.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Fengguang Wu <wfg@...l.ustc.edu.cn>, riel <riel@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Tim Pepper <lnxninja@...ibm.com>,
Chris Snook <csnook@...hat.com>
Subject: Re: [PATCH 3/3] readahead: scale max readahead size depending on
memory size
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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists