From: Marr <marr@flex.com>
To: Mark Lord <lkml@rtr.ca>
Cc: Linda Walsh <lkml@tlinx.org>, Bill Davidsen <davidsen@tmr.com>,
linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com,
Andrew Morton <akpm@osdl.org>,
marr@flex.com
Subject: Re: Readahead value 128K? (was Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?)
Date: Sun, 12 Mar 2006 23:36:55 -0500 [thread overview]
Message-ID: <200603122336.55701.marr@flex.com> (raw)
In-Reply-To: <44149D6A.7080005@rtr.ca>
On Sunday 12 March 2006 5:15pm, Mark Lord wrote:
> Marr wrote:
> > I tried turning 'readahead' off entirely ('hdparm -A0 /dev/hda') and,
> > although
>
> No, that should be "hdparm -a0 /dev/hda" (lowercase "-a").
Aha, you're right! Thanks for the clarification.
> And the same "-a" for all of your other test variants.
>
> If you did it all with "-A", then the results are invalid,
> and need to be redone.
Actually, that's impossible to do ('hdparm' won't take such settings with
'-A'). And, as my original email stated:
(Values shown for 'readahead' are set by 'hdparm -a## /dev/hda' command.)
In other words, the important tests were done correctly. Sorry I didn't make
it clearer, but that last test with '-A0' was a complete afterthought (based
on what I saw on a quick look at the 'man hdparm' page) and in no way negates
the results from the first part of the tests.
> The hdparm manpage explains this, but in a nutshell, "-A" is the
> low-level drive firmware "look-ahead" mechanism, whereas "-a" is
> the Linux kernel "read-ahead" scheme.
You are, of course, correct. Unfortunately, my 'man hdparm' page ("Version 6.1
April 2005") doesn't make this as clear as it could be. The distinction is
subtle. To quote the '-a'/'-A' part:
-a Get/set sector count for filesystem read-ahead. This is used to
improve performance in sequential reads of large files, by
prefetching additional blocks in anticipation of them being
needed by the running task. In the current kernel version
(2.0.10) this has a default setting of 8 sectors (4KB). This
value seems good for most purposes, but in a system where most
file accesses are random seeks, a smaller setting might provide
better performance. Also, many IDE drives also have a separate
built-in read-ahead function, which alleviates the need for a
filesystem read-ahead in many situations.
-A Disable/enable the IDE drive's read-lookahead feature (usually
ON by default). Usage: -A0 (disable) or -A1 (enable).
A bad interpretation on my part. Thanks again for setting me straight.
Anyway, not that it really matters, but I re-did the testing with '-a0' and it
didn't help one iota. The 2.6.13 kernel on ReiserFS (without using
'nolargeio=1' as a mount option) still takes about 4m35s to fseek 200,000
times on that 4MB file, even with 'hdparm -a0 /dev/hda' in effect.
*** Please CC: me on replies -- I'm not subscribed.
Regards,
Bill Marr
next prev parent reply other threads:[~2006-03-13 4:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-24 20:22 Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change? Marr
2006-02-25 5:16 ` Andrew Morton
2006-02-26 13:07 ` Ingo Oeser
2006-02-26 13:50 ` Nick Piggin
2006-02-26 14:11 ` Arjan van de Ven
2006-02-27 20:52 ` Hans Reiser
2006-02-28 0:34 ` Nick Piggin
2006-02-28 18:42 ` Hans Reiser
2006-02-28 18:51 ` Hans Reiser
2006-02-27 20:24 ` Marr
2006-02-27 21:53 ` Hans Reiser
2006-02-28 0:03 ` Bill Davidsen
2006-02-28 18:38 ` Hans Reiser
2006-03-05 23:02 ` Readahead value 128K? (was Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?) Linda Walsh
2006-03-07 19:53 ` Marr
2006-03-07 21:15 ` Linda Walsh
2006-03-12 21:53 ` Marr
2006-03-12 22:15 ` Mark Lord
2006-03-13 4:36 ` Marr [this message]
2006-03-13 14:41 ` Mark Lord
2006-03-13 18:15 ` Hans Reiser
2006-03-13 20:00 ` Marr
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=200603122336.55701.marr@flex.com \
--to=marr@flex.com \
--cc=akpm@osdl.org \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=lkml@tlinx.org \
--cc=reiserfs-dev@namesys.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