Messages in this thread | | | Date | Fri, 10 Mar 2000 18:07:12 +0100 | From | Jamie Lokier <> | Subject | Re: elevator messages in 2.3.50 |
| |
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/
| |