FATQW@USU.BITNET (02/21/88)
>...A request cannot be starved >because it must at most wat for the head to traver to one extreme and back. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ And why should it do this? The trackdisk device should have an internal flag stating the current direction of head movement. After it finishes a request, it looks in the direction specified by the flag and goes to the next request in that direction. If there aren't anymore requests in that direction, it does an about-face and starts going the other direction. If this was put in the trackdisk device, I think that something should be done in LoadSeg(), Read(), and Write(). For a long Read() or Write(), it should submit as many requests as possible to the trackdisk device at the same time, so the trackdisk device could optimize it. Just make sure LoadSeg() operates on big Read()s rather than lots of small ones. (I think this is already the case, but I'm not sure.) Bryan Bryan Ford //// A computer does what \\\\ Snail: 1790 East 1400 North //// you tell it to do, not \\\\ Logan, UT 84321 \\\XX/// what you want it to do. \\\XX/// Email: FATQW@USU.BITNET \XXXX/ Murphy's Law Calendar 1986 \XXXX/
keithd@cadovax.UUCP (Keith Doyle) (02/24/88)
In article <8802210532.AA14542@jade.berkeley.edu> FATQW@USU.BITNET writes: > The trackdisk device should have an internal >flag stating the current direction of head movement. After it finishes a >request, it looks in the direction specified by the flag and goes to the >next request in that direction. If there aren't anymore requests in that >direction, it does an about-face and starts going the other direction. > >If this was put in the trackdisk device, I think that something should be >done in LoadSeg(), Read(), and Write(). Ok, so now you want to modify LoadSeg(), Read(), and Write(), because you've realized that the basic problem with the elevator algorithm, is that it doesn't buy you anything until you have at least 3 tasks contending for the disk. But if you modify LoadSeg(), Read(), and Write() to just hog the disk until they finish their specific read (or a bigger chunk of it), that would have pretty much the same effect even if you didn't also implement the elevator algorithm. Then the only problem you have, is that while running some programs, other tasks will wait less often, but for longer periods of time, and the see-sawing of the disk happens a little less frequently. Tasks that do a bunch of small reads will act just like they do now. No matter what you do, the difference between one disk-bound task and two disk bound tasks, means see-sawing all over a floppy disk. You can cut it down a bit by giving each process a larger contiguous 'slice' of disk I/O, but that's about it. If it bothers you that much, then maybe it's time to get a hard disk. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170