Re: Readahead value 128K? (was Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?)

[Marr <marr@flex.com>]

On Sunday 05 March 2006 6:02pm, Linda Walsh wrote:
> Does this happen with a seek call as well, or is this limited
> to fseek?
>
> if you look at "hdparm's" idea of read-ahead, what does it say
> for the device?.  I.e.:
>
> hdparm /dev/hda:
>
> There is a line entitled "readahead".  What does it say?

Linda,

I don't know (based on your email addressing) if you were directing this 
question at me, but since I'm the guy who originally reported this issue, 
here are my 'hdparm' results on my (standard Slackware 10.2) ReiserFS 
filesystem:

   2.6.13 (with 'nolargeio=1' for reiserfs mount): 
      readahead    = 256 (on)

   2.6.13 (without 'nolargeio=1' for reiserfs mount): 
      readahead    = 256 (on)

   2.4.31 ('nolargeio' option irrelevant/unavailable for 2.4.x): 
      readahead    = 8 (on)

*** Please CC: me on replies -- I'm not subscribed.

Regards,
Bill Marr

> I noticed that this seems to default to "256" sectors, or 128K
> in 2.6.
>
> This may be unrelated, but what does the kernel do with
> this number?  I seem to remember this being set to ~8-16 (4-8K)
> in 2.4.  I thought it was the number of sectors to read ahead, by
> default, when a read was done, but I haven't noticed a performance
> degradation like I would expect for such a large read-ahead value.
>
> On the other hand: you do seem to be experiencing something consistent
> with that setting.  I'm not sure under what circumstances the kernel
> uses the "readahead" value as a number of sectors to read ahead...
>
> Have the disk read routines changed with respect to this value?
>
> -linda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/