From ded29eb19869805d3ea7cfb4a6257f61f6873bab Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Mon, 19 Jan 2004 05:11:52 -0800 Subject: [PATCH] [PATCH] revert lazy readahead From: Trond Myklebust The following reversion is what fixes my regression. That puts the sequential read numbers back to the 2.6.0 values of ~140MB/sec (from the current 2.6.1 values of 14MB/second)... We were triggering I/O of the `ahead' when we hit the last page in the `current' window. That's bad because it gives no pipelining at all. So go back to full pipelining. It's not at all clear why this change made a 10x difference in NFS throughput. --- mm/readahead.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/mm/readahead.c b/mm/readahead.c index 46a6ff8e1f65c..042376caeec62 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -449,12 +449,8 @@ do_io: * accessed in the current window, there * is a high probability that around 'n' pages * shall be used in the next current window. - * - * To minimize lazy-readahead triggered - * in the next current window, read in - * an extra page. */ - ra->next_size = preoffset - ra->start + 2; + ra->next_size = preoffset - ra->start + 1; } ra->start = offset; ra->size = ra->next_size; @@ -474,13 +470,9 @@ do_io: /* * This read request is within the current window. It is time * to submit I/O for the ahead window while the application is - * about to step into the ahead window. - * Heuristic: Defer reading the ahead window till we hit - * the last page in the current window. (lazy readahead) - * If we read in earlier we run the risk of wasting - * the ahead window. + * crunching through the current window. */ - if (ra->ahead_start == 0 && offset == (ra->start + ra->size -1)) { + if (ra->ahead_start == 0) { ra->ahead_start = ra->start + ra->size; ra->ahead_size = ra->next_size; actual = do_page_cache_readahead(mapping, filp, -- 2.53.0