Messages in this thread | | | Date | Thu, 9 Mar 2000 01:34:14 +0100 | From | Jamie Lokier <> | Subject | Re: elevator messages in 2.3.50 |
| |
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/
| |