Andrea Arcangeli wrote:
> I am now in the process of partially rewriting the request merging code so
> that I don't seek back and forth if not necessary. I am trying to exploit
> all possible optimizations.
You mean ordering to minimise seek time?
A possible improvement would be a small holdoff time between one request
and the next, if a large seek would be involved. The idea here is to
support applications which do a sequence of reads in a local region,
where each read is not queued until the previous one completes. The
hottest example is page-in but there are others.
The holdoff time would be just enough to permit an application to queue
the next request, if it is going to do that immediately. E.g. I have
process A doing lots of I/O. Details not important.
I also have process B. It reads something, sleeps, wakes up and quickly
issues a read for the next thing. That might be via paging or explicit
reads.
To minimise overall seek time, it is probably better to _not_ schedule
an I/O from process A in the short time between process B's two
requests, _if_ A's request would imply a large seek. However, the only
way to do that is to let the device idle for a short time. Sure it's
idle, but overall seek time is reduced.
Eventually when the elevator decides A's request has been waiting too
long, that request is sent to the device. Now the situation is
reversed, and if A is doing the same sort of thing, the disk will remain
in the region that A is working for a little while.
Do you see how this could reduce overall I/O time?
I would expect the best holdoff time to depend to be roughly
proportional to the expected seek time of the next request currently
suggested by the elevator.
To be precise it depends on whether the next I/O to enter the elevator
is likely to be nearer -- we don't know that, but we can estimate that
the further is the next pending I/O from the current head position, the
more likely is the chance of receiving a closer request from a recently
woken up task very soon.
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:14 EST