>No, I suggested holdoff to handle those cases where you _cannot_ predict
>the next block to be read.
I see a problem: increased latency and lower bandwith whenever
a long seek comes up. This will loose badly in the case when
a process reads from two files at either end of the disk.
"diff" and "patch" springs to mind, particularly when the
patchfile and source-tree are on different partitions.
A read from one file waits before the long jump to the other,
not realising that no read for the first area will happen until
the other area is read & processed.
I might even be able to speed up
patching by running something disk-intensive in between the
two files, as this would shorten the distance preventing waiting.
>For paging, readaround still does not predict the early sequence of
>accesses when a program starts
Seems to me that page-tuning the executable code is the best
solution here. It will minimize the number of early accesses,
minimize the working code-set, and give a linear layout that
works well with read-ahead.
Helge Hafting
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:17 EST