Messages in this thread |  | | Date | Wed, 7 Aug 1996 10:01:03 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: I/O request ordering |
| |
On Tue, 6 Aug 1996, Stephen C. Tweedie wrote: > > 5% seems an *awful* lot. There is a major problem with this sort of > window, which is that fairness is sacrificed. It's not uncommon to > have a lot of IO occurring at one part of the disk. The sawtooth > guarantees that the request pointer will eventually move on to other > requests. For example, take the case where there's a lot of syslog > activity; you'll have a file being constantly written to disk via > fsync, which can generate a lot of local write activity. You may > starve the rest of the system if you don't limit the amount of > backtracking allowed.
Yes. The problem is that we do need some kind of window, because I suspect the current strict sawtooth algorithm is very bad indeed for demand-loading executables. It's ok on an unloaded system, but executable loading time goes _way_ up if you're doing anything else disk-intensive at the same time. (Executable loading is hard, as the page-faults are totally synchronous. It may make sense to give priority to page-faulting or something like that)
If somebody does test with new sorting algorithms, I'd suggest doing something like
while true; do grep "not really found anywhere" `find /usr/src/linux -type f`
in fact, do something like the above on _two_ separate Linux trees in parallell, and then test how long it takes for programs to load etc "feel" of the system. Make sure the source-tree (or whatever) you're grepping on is larger than your physical memory, so that it doesn't work from the cache.
Linus
|  |