Messages in this thread | | | Date | Tue, 26 Sep 2000 22:00:12 +0200 (CEST) | From | Peter Osterlund <> | Subject | Re: [patch] vmfixes-2.4.0-test9-B2 |
| |
On Tue, 26 Sep 2000, Andrea Arcangeli wrote:
: > smaller with your algorithm? (I later realized that request merging is : > done before the elevator function kicks in, so your algorithm should : : Not sure what you mean. There are two cases: the bh is merged, or : the bh will be queued in a new request because merging isn't possible. : : Your change deals only with the latter case and that should be : pretty orthogonal to what the merging stuff does.
I previously thought that elevator_linus() was called first, and then elevator_linus_merge() was invoked to merge sequential requests before they were sent to the driver. If that had been the case, your version of elevator_linus() would have generated more seeks than CSCAN.
But as I said, I was mistaken, it doesn't work that way. The elevator_linus() function is only called if merging isn't possible. Therefore, no matter what algorithm you use in elevator_linus() the total number of seeks should be the same.
Therefore, if you are not trying to be fair (as CSCAN is) maybe there is an even better way to sort the requests. I think the important thing is trying to minimize the total amount of seek time. But doing that requires knowledge about how the seek time depends on the seek distance.
-- Peter Österlund Email: peter.osterlund@mailbox.swipnet.se Sköndalsvägen 35 f90-pos@nada.kth.se S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919 Sweden Phone: +46 8 942647
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |