Right. For example, the sawtooth/elevator scheme.
Full circle there.
With 1.1.xx and again with 1.3.xx, I have implemented the various
options discussed here, including:
(1) simple proper elevator
(2) elevator with minimal head movement tweaks
(3) pure minimal head movement
For overall batch performance, option (3) vastly outperformed the others
on my system. eg. reduced kernel rebuild time from 12 to 10 minutes,
and eliminated thrashing during heavy swapping. The latter was the
original goal of the experiment: trying to get the clumps of swapping
requests to be clustered in the request queue, to avoid a long series
of back and forth sweeps to and from the swap partition on the drive.
But (3) also introduced a certain amount of delay into some interactive
response applications, as expected.
Better overall was (2), which still heartily reduced overall execution
times for batch style operations, and still helped swapping to a degree,
but did not appear to noticeably impact interactive response.
This last finding contradicts much of the theory discussed here,
for which at least two explanations are possible:
(1) yes, it is more fair to the middle of the disk than
to the extremities. But is this really a problem?
the real concern here ought to be "are the extremities
significantly *disadvantaged* by this?" I see no problem
whatsoever making the middle of the disk "faster", so long
as the outside ends are not made significantly slower as a
result.
(2) I have *very* fast drives: Quantum Fireball 1080A units.
These drives transfer data so quickly that they don't seem
to take much longer to "stop and read on the way" than they
do to just do a full sawtooth seek across the disk.
With slower non-ATA2 drives, the penalty for reading is
much higher. (the Fireballs burst at 16.6MByte/sec,
(and sustain 6MByte/sec, older drives are much slower).
My other drive is an older pre-ATA2 drive, transfering
data at around 2.5MB/sec. But it too was advantaged by
a proper elevator queuing scheme. But again, I think this
drive may have an unfair advantage in it's 1.5ms track-to-
track seek time, twice as fast as 99% of other drives.
When I finally upgraded from 16MB to 32MB of DRAM, the full elevator
scheme and the sawtooth became indistinguishable. This is due to the
system just about never having to swap anymore.
-ml
the Linux IDE guy