From: Paolo Ornati <ornati@lycos.it>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
gandalf@wlug.westbo.se, linux-kernel@vger.kernel.org
Subject: Re: Strange IDE performance change in 2.6.1-rc1 (again)
Date: Wed, 7 Jan 2004 15:59:16 +0100 [thread overview]
Message-ID: <200401071559.16130.ornati@lycos.it> (raw)
In-Reply-To: <1073344795.3088.19.camel@dyn319250.beaverton.ibm.com>
On Tuesday 06 January 2004 00:19, you wrote:
> Sorry I was on vacation and could not get back earlier.
>
> I do not exactly know the reason why sequential reads on blockdevices
> has regressed. One probable reason is that the same lazy-read
> optimization which helps large random reads is regressing the sequential
> read performance.
>
> Note: the patch, waits till the last page in the current window is being
> read, before triggering a new readahead. By the time the readahead
> request is satisfied, the next sequential read may already have been
> requested. Hence there is some loss of parallelism here. However given
> that largesize random reads is the most common case; this patch attacks
> that case.
>
> If you revert back just the lazy-read optimization, you might see no
> regression for sequential reads,
I have tried to revert it out:
--- mm/readahead.c.orig 2004-01-07 15:17:00.000000000 +0100
+++ mm/readahead.c.my 2004-01-07 15:33:13.000000000 +0100
@@ -480,7 +480,8 @@
* If we read in earlier we run the risk of wasting
* the ahead 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;
but the sequential read performance is still the same !
Reverting out the other part of the patch (that touches mm/filemap.c) the
sequential read performance comes back like in 2.6.0.
I don't know why... but it does.
>
> Let me see if I can verify this,
> Ram Pai
>
Bye
--
Paolo Ornati
Linux v2.4.23
next prev parent reply other threads:[~2004-01-07 14:59 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-02 16:02 Strange IDE performance change in 2.6.1-rc1 (again) Paolo Ornati
2004-01-02 18:08 ` Ed Sweetman
2004-01-02 21:04 ` Paolo Ornati
2004-01-02 21:27 ` Valdis.Kletnieks
2004-01-03 10:20 ` Paolo Ornati
2004-01-02 21:32 ` Mike Fedyk
2004-01-02 22:34 ` Martin Josefsson
2004-01-03 11:13 ` Paolo Ornati
2004-01-03 22:40 ` Andrew Morton
2004-01-04 14:30 ` Paolo Ornati
2004-01-05 23:19 ` Ram Pai
2004-01-07 14:59 ` Paolo Ornati [this message]
2004-01-07 19:23 ` Ram Pai
2004-01-07 20:12 ` Paolo Ornati
2004-01-07 23:57 ` Andrew Morton
2004-01-08 7:31 ` Ram Pai
2004-01-09 1:05 ` Ram Pai
2004-01-09 1:17 ` Andrew Morton
2004-01-09 19:15 ` Ram Pai
2004-01-09 19:44 ` Andrew Morton
2004-01-10 14:48 ` Paolo Ornati
2004-01-10 16:00 ` Ed Sweetman
2004-01-10 16:19 ` Ed Sweetman
2004-01-10 17:29 ` Paolo Ornati
2004-01-10 17:29 ` Paolo Ornati
2004-03-29 15:45 ` Ram Pai
2004-01-04 17:15 ` Buffer and Page cache coherent? was: " Mike Fedyk
2004-01-04 22:10 ` Andrew Morton
2004-01-04 23:22 ` Mike Fedyk
2004-01-04 23:32 ` Andrew Morton
2004-01-04 23:45 ` Mike Fedyk
2004-01-05 0:23 ` Andrew Morton
2004-01-03 10:20 ` Paolo Ornati
2004-01-03 3:33 ` Tobias Diedrich
2004-01-03 4:15 ` Valdis.Kletnieks
2004-01-03 13:39 ` Tobias Diedrich
2004-01-03 20:56 ` Tobias Diedrich
2004-01-04 3:02 ` jw schultz
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=200401071559.16130.ornati@lycos.it \
--to=ornati@lycos.it \
--cc=akpm@osdl.org \
--cc=gandalf@wlug.westbo.se \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.