Pipelined readahead behaviour is suitable for sequential reads, but not for
large random reads (typical of database workloads), where lazy readahead
provides a big performance boost.
One option (suggested by Andrew Morton) would be to have the application
pass hints to turn off readahead by setting the readahead window to zero
using posix_fadvise64(POSIX_FADV_RANDOM), and to special-case that in
do_generic_mapping_read to completely bypass the readahead logic and
instead read in all the pages needed directly.
This was the idea I started with. But then I thought, we can do a still
better job ? How about adapting the readahead algorithm to lazy-read or
non-lazy-read based on the past i/o patterns ?
The overall idea is to keep track of average number of contiguous pages
accessed in a file. If the average at any given time is above ra->pages
the pattern is sequential. If not the pattern is random. If pattern is
sequential do non-lazy-readahead( read as soon as the first page in the
active window is touched) else do lazy-readahead.
I have studied the behaviour of this patch using my user-level simulator.
It adapts pretty well.
Note from Suparna: This appears to bring streaming AIO read performance for
large (64KB) random AIO reads back to sane values (since the lazy readahead
backout in the mainline).