I've seen other OS's do something with the disk I/O schedualing that Linux
doesn't but I think might be a better solution than delaying a read for example
that involved a large seek.
What I've seen done in other OS's is to have to pending disk request
queues, one "in" queue, and one "out" queue. While the "in" queue was being
processed, any new requests would be added to the "out" queue, when processing
completed of the "in" queue, the OS would start processing the "out" queue and
new requests would be added to the "in" queue. When the processing of the
"out" queue was completed processing would go back to the "in" queue again and
new requests would be added to the "out" queue again.
Both queues were B-tree's with the sorting by clinder number (could be by
block number if the physical layout of the disk was unknown or calculating the
cylinder would be too much overhead), the "in" queue would walk the tree from
the lowest to the highest cylinder number during processing, the "out" queue
would walk the tree from the highest to the lowest cylinder number during
processing.
This would absolutely minimize time spent seeking while never delaying any
request infinitely.
-
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:15 EST