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/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:18 EST