Yes I understand that. Cases for random-reads and other non-sequential workloads, readahead logic will not ramp up to max size anyway. What I want is to bump up max size, so that when kernel detects sequential worklaod it does not restrict itself to 32 pages.
I looked around and saw an old patch that tried to account for actual memory on the system and setting max_readahead according to that. Restricting to arbitrary limits -- for instance think 512MB system vs 4GB system - is not sane IMO. Shailesh Jain On Fri, Sep 25, 2009 at 6:00 PM, Peter Teoh <[email protected]> wrote: > On Fri, Sep 25, 2009 at 12:05 AM, shailesh jain > <[email protected]> wrote: > > Hi, > > Is the maximum limit of readahead 128KB ? .. Can it be changed by FS > > kernel module ? > > > > > > Shailesh Jain > > > > not sure why u want to change that? for a specific performance > tuning scenario (lots of sequential read)? this readahead feature is > useful only if u are intending on reading large files. But if u > switch to a different files, assuming many small files, u defeats the > purpose of readahead. i think this is an OS-independent features, > which is specifically tuned to the normal usage of the filesystem. > > so, for example for AIX: > > > http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/seq_read_perf_tuning.htm > > their readahead is only (max) 16xpagesize. not sure how big is that, > but our 128KB should be > 16xpagesize (how big is our IO blocksize > anyway?) > > for another reputable references: > > http://www.dba-oracle.com/t_read_ahead_cache_windows.htm > > (in Oracle database). > > The problem is that if u read ahead too much, and after that the > entire buffer is going to be thrown away due to un-use, then a lot of > time is wasted in reading ahead. > > -- > Regards, > Peter Teoh >
