public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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