> >It's a good way to avoid stalls, but IMHO I thing the elevator should
>
> Here you're talking about the latency control logic.
Which is tightly dependent on the way we insert new rqs.
> >not work this way. The main problem is that it doesn't minimize head
> >movement. For example, when comes a request for a sector at the
>
> The algorithm that control the latency and the one that enforce the
> ordering are two separate things.
>
> For example in 2.2.15 there's only the latter (2.2.15 was missing a
> latency control mechanism).
>
> >beginning of the disk it goes to the beginning of the queue (it's
> >ordered) so it will be serviced before other rqs (it picks up rqs from
> >the head). This way the higher is the block number, more likely that
> >rq will wait a lot.
>
> We're not using a SCAN ordering algorithm it's instead a CSCAN. The queue
> can be for istance:
>
> 12 13 14 1 2 3
>
> Now insert 15 (assume 15 is the last sector of the disk):
>
> 12 13 14 15 1 2 3
Rqs are added according to the IN_ORDER() condition which enforces ascending
ordering. What does CSCAN mean ?
ie, if the queue initially is 1 2 3 it will become 1 2 3 14.
If it's 12 13 14 and we insert 2: 2 12 13 14.
So your example can happen only if the list is 12 13 14 and "14" is the
latency barrier. When we insert 15 the list becomes 12 13 14 1 2 3 15.
Am I missing something ?
> PS. Thanks for having read and understood the internals of the 2.4.x
> elevator before posting your comments, it simplifies very much the
> communication.
I had to study it while hunting for the no-merge bug :)
Bye.
-
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 : Fri Sep 15 2000 - 21:00:26 EST