From: Ram Pai <linuxram@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: alexeyk@mysql.com, nickpiggin@yahoo.com.au, peter@mysql.com,
linux-kernel@vger.kernel.org, axboe@suse.de
Subject: Re: Random file I/O regressions in 2.6
Date: 11 May 2004 13:51:47 -0700 [thread overview]
Message-ID: <1084308706.25954.28.camel@localhost.localdomain> (raw)
In-Reply-To: <20040510160740.5db8c62c.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]
On Mon, 2004-05-10 at 16:07, Andrew Morton wrote:
> Ram Pai <linuxram@us.ibm.com> wrote:
> >
> > I am nervous about this change. You are totally getting rid of
> > lazy-readahead and that was the optimization which gave the best
> > possible boost in performance.
>
> Because it disabled the large readahead outside the area which the app is
> reading. But it's still reading too much.
> > Let me see how this patch does with a DSS benchmark.
>
> That was not a real patch. More work is surely needed to get that right.
>
> > In the normal large random workload this extra page would have
> > compesated for all the wasted readaheads.
>
> I disagree that 64k is "normal"!
>
> > However in the case of
> > sysbench with Andrew's ra-copy patch the readahead calculation is not
> > happening quiet right. Is it worth trying to get a marginal gain
> > with sysbench at the cost of getting a big hit on DSS benchmarks,
> > aio-tests,iozone and probably others. Or am I making an unsubstantiated
> > claim? I will get back with results.
>
> It shouldn't hurt at all - the app does a seek, we perform the
> correctly-sized read.
Looks like you are right on all counts! I did some modifications to your
patch and did a preliminary run with my user-level simulator. With these
changes I am able to get rid of that extra page. Also code looks much
simpler and adapts well to sequential and random patterns.
However I have to run this under some benchmarks and see how it fares.
Its a pre-alpha level patch.
Can you take a quick look at the changes and see if you like it? I am
sure you won't consider these changes a hack ;)
RP
[-- Attachment #2: readahead_trim.patch --]
[-- Type: text/x-patch, Size: 3130 bytes --]
diff -urNp linux-2.6.6/mm/readahead.c linux-2.6.6.new/mm/readahead.c
--- linux-2.6.6/mm/readahead.c 2004-05-09 19:32:00.000000000 -0700
+++ linux-2.6.6.new/mm/readahead.c 2004-05-11 20:26:51.288797696 -0700
@@ -353,7 +353,7 @@ page_cache_readahead(struct address_spac
unsigned orig_next_size;
unsigned actual;
int first_access=0;
- unsigned long preoffset=0;
+ unsigned long average=0;
/*
* Here we detect the case where the application is performing
@@ -394,10 +394,17 @@ page_cache_readahead(struct address_spac
if (ra->serial_cnt <= (max * 2))
ra->serial_cnt++;
} else {
- ra->average = (ra->average + ra->serial_cnt) / 2;
+ /* to avoid rounding errors, ensure that 'average'
+ * tends towards the value of ra->serial_cnt.
+ */
+ if(ra->average > ra->serial_cnt) {
+ average = ra->average - 1;
+ } else {
+ average = ra->average + 1;
+ }
+ ra->average = (average + ra->serial_cnt) / 2;
ra->serial_cnt = 1;
}
- preoffset = ra->prev_page;
ra->prev_page = offset;
if (offset >= ra->start && offset <= (ra->start + ra->size)) {
@@ -457,18 +464,14 @@ do_io:
* ahead window and get some I/O underway for the new
* current window.
*/
- if (!first_access && preoffset >= ra->start &&
- preoffset < (ra->start + ra->size)) {
- /* Heuristic: If 'n' pages were
- * 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.
+ if (!first_access) {
+ /* Heuristic: there is a high probability
+ * that around ra->average number of
+ * pages shall be accessed in the next
+ * current window.
*/
- ra->next_size = preoffset - ra->start + 2;
+ ra->next_size = (ra->average > max ?
+ max : ra->average);
}
ra->start = offset;
ra->size = ra->next_size;
@@ -492,21 +495,19 @@ do_io:
*/
if (ra->ahead_start == 0) {
/*
- * if the average io-size is less than maximum
+ * If the average io-size is more than maximum
* readahead size of the file the io pattern is
* sequential. Hence bring in the readahead window
- * immediately.
- * Else the i/o pattern is random. Bring
- * in the readahead window only if the last page of
- * the current window is accessed (lazy readahead).
+ * immediately.
+ * If the average io-size is less than maximum
+ * readahead size of the file the io pattern is
+ * random. Hence don't bother to readahead.
*/
- unsigned long average = ra->average;
-
+ average = ra->average;
if (ra->serial_cnt > average)
- average = (ra->serial_cnt + ra->average) / 2;
+ average = (ra->serial_cnt + ra->average + 1) / 2;
- if ((average >= max) || (offset == (ra->start +
- ra->size - 1))) {
+ if (average > max) {
ra->ahead_start = ra->start + ra->size;
ra->ahead_size = ra->next_size;
actual = do_page_cache_readahead(mapping, filp,
next prev parent reply other threads:[~2004-05-11 20:52 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-02 19:57 Random file I/O regressions in 2.6 Alexey Kopytov
2004-05-03 11:14 ` Nick Piggin
2004-05-03 18:08 ` Andrew Morton
2004-05-03 20:22 ` Ram Pai
2004-05-03 20:57 ` Andrew Morton
2004-05-03 21:37 ` Peter Zaitsev
2004-05-03 21:50 ` Ram Pai
2004-05-03 22:01 ` Peter Zaitsev
2004-05-03 21:59 ` Andrew Morton
2004-05-03 22:07 ` Ram Pai
2004-05-03 23:58 ` Nick Piggin
2004-05-04 0:10 ` Andrew Morton
2004-05-04 0:19 ` Nick Piggin
2004-05-04 0:50 ` Ram Pai
2004-05-04 6:29 ` Andrew Morton
2004-05-04 15:03 ` Ram Pai
2004-05-04 19:39 ` Ram Pai
2004-05-04 19:48 ` Andrew Morton
2004-05-04 19:58 ` Ram Pai
2004-05-04 21:51 ` Ram Pai
2004-05-04 22:29 ` Ram Pai
2004-05-04 23:01 ` Alexey Kopytov
2004-05-04 23:20 ` Andrew Morton
2004-05-05 22:04 ` Alexey Kopytov
2004-05-06 8:43 ` Andrew Morton
2004-05-06 18:13 ` Peter Zaitsev
2004-05-06 21:49 ` Andrew Morton
2004-05-06 23:49 ` Nick Piggin
2004-05-07 1:29 ` Peter Zaitsev
2004-05-10 19:50 ` Ram Pai
2004-05-10 20:21 ` Andrew Morton
2004-05-10 22:39 ` Ram Pai
2004-05-10 23:07 ` Andrew Morton
2004-05-11 20:51 ` Ram Pai [this message]
2004-05-11 21:17 ` Andrew Morton
2004-05-13 20:41 ` Ram Pai
2004-05-17 17:30 ` Random file I/O regressions in 2.6 [patch+results] Ram Pai
2004-05-20 1:06 ` Alexey Kopytov
2004-05-20 1:31 ` Ram Pai
2004-05-21 19:32 ` Alexey Kopytov
2004-05-20 5:49 ` Andrew Morton
2004-05-20 21:59 ` Andrew Morton
2004-05-20 22:23 ` Andrew Morton
2004-05-21 7:31 ` Nick Piggin
2004-05-21 7:50 ` Jens Axboe
2004-05-21 8:40 ` Nick Piggin
2004-05-21 8:56 ` Spam: " Andrew Morton
2004-05-21 22:24 ` Alexey Kopytov
2004-05-21 21:13 ` Alexey Kopytov
2004-05-26 4:43 ` Alexey Kopytov
2004-05-11 22:26 ` Random file I/O regressions in 2.6 Bill Davidsen
2004-05-04 1:15 ` Andrew Morton
2004-05-04 11:39 ` Nick Piggin
2004-05-04 8:27 ` Arjan van de Ven
2004-05-04 8:47 ` Andrew Morton
2004-05-04 8:50 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1084308706.25954.28.camel@localhost.localdomain \
--to=linuxram@us.ibm.com \
--cc=akpm@osdl.org \
--cc=alexeyk@mysql.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=peter@mysql.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox