On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall <dave(a)horsfall.org> wrote:
Dave Horsfall writes:
On Tue, 8 Jan 2019, Warner Losh wrote:
i understood that this implemented the
elevator algorithm, and
possible rotational latency compensation.
I know what it does. I want to know why that specific name was selected.
Err, because as I replied in a previous message (did you not see it?), it
was up to the programmer to implement an optimal strategy to access the
sectors, depending upon the device? I'm not being snarky, but it seems
like an obvious choice (if not a hint) to me...
Let's see, I need a strategy to optimise access, taking into account
seek and rotational latency. I know! I'll call it XXstrategy()!
I too wondered about "strategy" in 1981 when I first worked on
unix disk drivers. My guess then was something similar.
Anything other than a FIFO strategy would improve throughput
or fairness or avoid starvation but was much more complex due
to the fact you can't reoder reads & writes. My guess is the
original author who named it strategy had this in mind.
But these are not exactly dependent on the vagaries of
individual disk drivers. At some point I factoroued out code
so that each specific disk driver took about 1KB of code and
shared about 7KB of common code.
For example, I could envisage a disk where the sectors
are deliberately
not numbered sequentially i.e. they've taken rotational latency into
account for you?
We did in fact use an interleave factor of more than 1 (skip
more than 1 block for consecutively numbered sectors) to
improve throughput but that had to do with slow processing.
We did discuss "dead reckoning" (invoking the service routine
right when the N+1 numbered sector was near the r/w heads) but
I don't think we implemented it.