On Thu, 29 Jul 1999 14:45:51 -0400 (EDT), Chuck Lever <cel@monkey.org>
said:
> that means i either have to special-case the first cluster or read two
> clusters for the first cluster. i'll think about this some more.
Exactly. Once you have recognised sequential access, increasing the
effective IO size is exactly what you want to do anyway. You should
even think about extending the readahead to 3 or more clusters.
> so, i think the information needs to be in the file struct so that shared
> maps don't continue to read ahead a file that is already in the page
> cache.
I don't understand. We're optimising for the normal case. Readahead
for already scheduled IO is harmless. What is the problem?
> that value looks too small to me. we are trying to read ahead only mmaped
> files that are accessed strictly sequentially, so it seems like
> filemap_nopage can safely schedule more pages than the normal speculative
> file read-ahead case.
The max-readahead table already gives the upper bound for the extension
of dynamic file readahead for strictly sequential normal file reads.
The actual IO in both cases is identical. I can't think of a single
reason why we'd want to optimise the readahead differently in the two
cases.
--Stephen
-
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/