Rogier Wolff wrote:
> 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.
About 18 months ago I wrote "treescan", a program to search through
directories like "find". It does something similar. It guesses, from
the inode number, the best order to stat() inodes to get the same sort
of seek behaviour as you did with fsck.minix.
In general this gives a perceptible improvement, about maybe 30-50%
faster than find alone. Enough that I often run treescan before find or
du just to prime the inode cache.
However on the Squid cache directory which motivated me to write the
program in the first place, stat()ing all the entries went from about 2
minutes to 6.7 seconds. A _big_ improvement, just from seeking
sensibly.
> 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.
I tried doing multiple concurrent stat() calls, to let the kernel sort
out the requests as it knows the geometry better than I do and also so
that the request queue to always contain at least one entry.
Unfortunately the overhead for threading (using just clone(), no
pthreads overhead) made it slower.
-- Jamie
-
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