> quite the opposite. the goal of read-ahead is to prevent waiting for
> i/o, not to reduce the overall number of blocks read.
>
> ideally, a non-enabled OS would read exactly the pages needed by an
> application. this would be slow, but would read the least number of
> pages. read-ahead, because it is speculative, will almost certainly read
> extra pages that will not be required by the application. thus any
> read-ahead algorithm will generate more i/o than not reading ahead at all.
> however, as the number of extra pages read during read-ahead increases,
> the overall efficiency of the system as a whole drops, since reading extra
> pages lowers the maximum rate the OS can fulfill disk requests from
> applications.
Here's where I'm not quite following you -- do you agree that read-ahead
is a good thing? The statement that overall efficiency of the system
drops as readahead is increased is, in my opinion, false. Modern disks
can pull sequential data in quite well, but if you cease requesting for
long enough, you'll slip and have to wait another rotation of the disk to
get the data you're interested in (remember: modern disks may be fast, but
quite a few only have 128 or 512k buffers). This isn't a problem for apps
where you're simply copying data around and doing nothing of interest as
the time between requests is negligable, but for something like a video
stream or if there's more than one app pulling off the disk (and another
app requests data from somewhere else on the disk), it's fatal.
However, if you're arguing that blindly pulling in a cluster's worth of
data without any real heuristics is somewhat detrimental to peformance, I
agree. Personally I'd like to see the same intelligence used on both
files and mmaps (even metadata in some cases) as their access patterns are
often interchangable (think samba, grep, ...).
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/