Re: Fwd: Adaptive read-ahead V12

[Wu Fengguang <wfg@mail.ustc.edu.cn>]

On Wed, May 31, 2006 at 04:17:58PM -0400, Bill Davidsen wrote:
> Wu Fengguang wrote:
> >----- Forwarded message from Iozone <capps@iozone.org> -----
> >
> >Subject: Adaptive read-ahead V12
> >From: Iozone <capps@iozone.org>
> >To: Wu Fengguang <wfg@mail.ustc.edu.cn>
> >X-Mailer: Microsoft Outlook Express 6.00.2900.2670
> >Date: Thu, 25 May 2006 11:44:37 -0500
> >
> >Wu Fengguang,
> >
> >       I see that Andrew M. is giving you some pushback.... 
> >   His argument is that the application could do a better job
> >   of scheduling its own read-ahead.  ( I've heard this one 
> >   before)
> >
> >   My thoughts on this argument would be along the 
> >   lines of:
> >
> >   Indeed the application might be able to do a better
> >   job, however expecting, or demanding, the rewrite
> >   of all applications to behave better might be an unreasonable
> >   expectation. 
> 
> A reasonable expectation would be that the application would have a way 
> to tell the kernel to ignore readahead for a given file, other than 
> changing the behavior of the kernel as a whole for all processes on the 
> machine. This smart application could then use aio or some other similar 
> method to do preread itself.

Sure. The adaptive readahead works fine with user level readahead via
the readahead() or posix_fadvise() syscall. I.e. if a program do
necessary readahead() calls that can cover all the file pages
requested by the following read() calls, it avoids triggering
unnecessary kernel readaheads.

> My personal opinion is that the kernel only does a good job reading 
> ahead for sequential access, and since that's the common case only a 
> means of preventing that effort need be provided.

posix_fadvise(fd, ..., POSIX_FADV_RANDOM) can do the trick for a file.
blockdev --setra 0 /dev/hda  does so for a device.

Wu