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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:31 EST