From: Bakul Shah <bakul@bitblocks.com>
To: Dave Horsfall <dave@horsfall.org>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] TUHS Digest, Vol 38, Issue 10
Date: Tue, 08 Jan 2019 21:19:57 -0800 [thread overview]
Message-ID: <20190109052004.9DB6F156E410@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Wed, 09 Jan 2019 13:10:18 +1100." <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall <dave@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.
next prev parent reply other threads:[~2019-01-09 5:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
2019-01-08 10:15 ` Steve Simon
2019-01-08 11:00 ` Andreas Kusalananda Kähäri
2019-01-08 14:58 ` Warner Losh
2019-01-09 2:10 ` Dave Horsfall
2019-01-09 4:23 ` Warner Losh
2019-01-09 19:13 ` Christian Barthel
2019-01-09 5:19 ` Bakul Shah [this message]
2019-01-09 5:45 ` Warner Losh
2019-01-09 15:09 ` Bakul Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190109052004.9DB6F156E410@mail.bitblocks.com \
--to=bakul@bitblocks.com \
--cc=dave@horsfall.org \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).