Helge Hafting wrote:
> >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.
It shouldn't. If it does, the holdoff time is too long. It is supposed
to be short enough that it doesn't have much impact on the long seek
cases even when nothing fills the gap. For example, 10ms would be far
too long. Even 1ms would be far too long.
> "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.
See also the self-tuning variant, in which would be turned off in this
case.
> 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.
No it wouldn't :-) The holdoff timer would be restarted before each
request that looks like a long seek.
> >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.
I agree, paging prediction should be tuned as much as possible. Data
pages as well as code pages. Though it should be generalised to disk
block reordering according to predicted access patterns. Mere
executable page reordering doesn't help programs like Emacs which load
lots of files.
For things like Emacs and Netscape that would be a big improvment -- one
long readahead would load everything as fast as possible without any
seeks.
But no matter how much you optimise read prediction, there is still room
for dealing with unpredictable accesses. Programs still traverse
different data structures according to what they've been asked to do,
and they still call functions in an order that depends on what they've
been asked to do.
I hope I've shown how even unpredictable accesses can be accomodated
with a potentially big improvement, at minimal cost to the predictable
accesses. Not as good as predicting the access in the first place, but
that's the point: a certain amount of activity is not predictable at all.
-- Jamie
-
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:18 EST