question about max_readahead for ide devices in 2.4?

question about max_readahead for ide devices in 2.4?

[John Salmon]

Several "tuning" recommendations suggest that sequential accesses of
large files, and hence the performance of busy web servers, can be improved
by changing the maximum readahead value with, e.g.,

echo 511 > /proc/sys/vm/max-readahead

But it looks to me like get_max_readahead in filemap.c ignores the
value set by /proc/sys in favor of max_readahead[major][minor] whenever
max_readahead[major] is non-NULL.  And furthermore that 
max_readahead[major] IS initialized to non-NULL for ide devices in
init_gendisk.  (N.B. I'm looking at 2.4 sources).

Conclusion: echoing a value into /proc/sys/vm/max-readahead won't change the
readahead behavior for already-probed IDE devices.

Is this correct, or am I missing something?

Thanks,
John Salmon

Re: question about max_readahead for ide devices in 2.4?

[Andrew Morton]

John Salmon <jsalmon@thesalmons.org> wrote:
>
> 
> 
> Several "tuning" recommendations suggest that sequential accesses of
> large files, and hence the performance of busy web servers, can be improved
> by changing the maximum readahead value with, e.g.,
> 
> echo 511 > /proc/sys/vm/max-readahead
> 
> But it looks to me like get_max_readahead in filemap.c ignores the
> value set by /proc/sys in favor of max_readahead[major][minor] whenever
> max_readahead[major] is non-NULL.  And furthermore that 
> max_readahead[major] IS initialized to non-NULL for ide devices in
> init_gendisk.  (N.B. I'm looking at 2.4 sources).
> 
> Conclusion: echoing a value into /proc/sys/vm/max-readahead won't change the
> readahead behavior for already-probed IDE devices.
> 
> Is this correct, or am I missing something?

That's correct - it's all a bit weird.   You should use

	blockdev --setra 511 /dev/hda

for IDE devices.  Not sure about scsi.  You may as well set
/proc/sys/vm/max-readahead to the same thing.

Re: question about max_readahead for ide devices in 2.4?

[John Salmon]

>>>>> "Andrew" == Andrew Morton <akpm@osdl.org> writes:

Andrew> John Salmon <jsalmon@thesalmons.org> wrote:
>> 
>> 
>> 
>> Several "tuning" recommendations suggest that sequential accesses of
>> large files, and hence the performance of busy web servers, can be improved
>> by changing the maximum readahead value with, e.g.,
>> 
>> echo 511 > /proc/sys/vm/max-readahead
>> 
>> But it looks to me like get_max_readahead in filemap.c ignores the
>> value set by /proc/sys in favor of max_readahead[major][minor] whenever
>> max_readahead[major] is non-NULL.  And furthermore that 
>> max_readahead[major] IS initialized to non-NULL for ide devices in
>> init_gendisk.  (N.B. I'm looking at 2.4 sources).
>> 
>> Conclusion: echoing a value into /proc/sys/vm/max-readahead won't change the
>> readahead behavior for already-probed IDE devices.
>> 
>> Is this correct, or am I missing something?

Andrew> That's correct - it's all a bit weird.   You should use

Andrew> 	blockdev --setra 511 /dev/hda

Andrew> for IDE devices.  Not sure about scsi.  You may as well set
Andrew> /proc/sys/vm/max-readahead to the same thing.

Are you sure?  It looks like that invokes the BLKRASET ioctl, which
sets an entry in the read_ahead[MAJOR(dev)] array.  But the only code
that uses the read_ahead[] array is in fs/hfs/file.c, and I'm definitely
not using an hfs filesystem.

Or am I missing something else??

Thanks,
John Salmon

P.S.  The weird thing is that I tried the blockdev --setra suggestoin
and it *seemed to* improve performance.  This is why drug tests are
double-blind ... the patient (the computer) may not be susceptible to
the placebo effect, but the doctor (me) may be :-(.