Re: I/O request ordering

Linus Torvalds (torvalds@cs.helsinki.fi)
Wed, 7 Aug 1996 10:01:03 +0300 (EET DST)


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