lkml.org 
[lkml]   [2006]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Readahead value 128K? (was Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?)
Date
On Tuesday 07 March 2006 4:15pm, Linda Walsh wrote:
> Marr wrote:
> > 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
>
> --------
> Could you retry your test with read-ahead set to a smaller
> value? Say the same as in 2.4 (8) or 16 and see if that changes
> anything?
>
> hdparm -a8 /dev/hdx
> or
> hdparm -a16 /dev/hdx

Linda (et al),

Sorry for the delayed reply. I finally got a chance to run another test (but
on a different machine than the last time, so don't try to compare old timing
numbers with these numbers).

I went ahead and tried all permutations, just to be sure. As before, these
reported times are all for 200,000 random 'fseek()' calls on the same
zero-filled 4MB file on a standard Slackware 10.2 ReiserFS partition and
kernels.

(Values shown for 'readahead' are set by 'hdparm -a## /dev/hda' command.)

-----------------------------------
Timing Results:

On 2.6.13, *without* 'nolargeio=1': 4m35s (ouch!) for _all_ variants (256, 16,
8) of 'readahead'

On 2.6.13, _with_ 'nolargeio=1': 0m6s for _all_ variants (256, 16, 8) of
'readahead'

On 2.4.31: 0m6s for _all_ variants (128 [256 is illegal -- 'BLKRASET failed:
Invalid argument'], 16, 8) of 'readahead'

-----------------------------------

I half-expected to see improvement for the '2.6.13 without nolargeio=1' case
when lowering the read-ahead from 256 sectors to 16 or 8 sectors, but there
clearly was no improvement whatsoever.

I tried turning 'readahead' off entirely ('hdparm -A0 /dev/hda') and, although
it correctly reported "setting drive read-lookahead to 0 (off)", an immediate
follow-on query ('hdparm /dev/hda') showed that it was still ON ("readahead =
256 (on)")! I went ahead and ran the test again anyway and (unsurprisingly)
got the same excessive times (4m35s) for 200K seeks.

Confused, but still (for now) happily using the 'nolargeio=1' workaround with
all my 2.6.13 kernels with ReiserFS.... :^/

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

Regards,
Bill Marr
-
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/

\
 
 \ /
  Last update: 2006-03-12 22:57    [W:0.129 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site