Messages in this thread | | | Subject | Re: ORBS Elevator... | Date | Sun, 30 Jul 2000 09:39:25 +0200 (MEST) | From | (Rogier Wolff) |
| |
Andre Hedrick wrote: > > | +------ LBA 0 top of platter. > | +----- LBA End top of platter. > |----------------------------------- > | > +--- axis of rotation. > > We do a C or inverted Q position loop, real basic stuff for prediction by > knowing the characteristic of the media in a documented way.
Please excuse my rambling...
I once rewrote "fsck.minix" (under Linux -> you can guess the date!), because it was seeking so much.
So instead of
if (isdir (curinode)) read_and_handle_directory (curinode)
inside the mainloop, it would have a queue of "blocks I know I'm going to need" and it would read the first. That would cause a bunch of new blocks being needed. These would be added into the sorted list. We'd just continue walking the list, so lower blocks would be handled on the next pass over the media, but new blocks that were in our path would be taken along immediately.
This reduced the fsck of a floppy from 28 seconds to 26. This proved to me that this was an interesting project, but it was not going to lead to dramatic improvements.
Note that it actually worked: you only had to do somethign like 4 or 5 elevator passes over the media before you had fsck-ed all the disk.
Now on a modern Linux machine, can the kernel improve a lot on disk access times?
One of the main problems is that in average use, there is just one or two threads reading stuff from the disk. The threads will be "blocked waiting for IO to complete" and issue their next IO request after they have the results of the current IO. So at most there will be just one or two requests in the disk queue that you can order either the right way around, or the wrong way around.
Where it DOES make a difference doing things right, is in writing. We write-cache a lot of blocks. At the moment when we come into memory pressure or some time has elapsed, we start throwing data over the wall to the disk subsystem to write them to disk. If the disk subsystem could then indicate which blocks it can write also with VERY little overhead, then that would increase write speed significantly.
So, even when there isn't any memory pressure and no timeout has triggered, when you're writing block n, you should also write block n+1 if it happens to be dirty.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********
- 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/
| |