I meant:
"By the way, has anybody tried my block device access logger yet?"
> Intel did something like this for windows95.
>
> Another idea that might work with less disruption than moving blocks on
> the disk would be a 'working set map'. That's a bitmap associated with the
> binary that has bits set for all blocks that are needed during startup.
> This bitmap could be feed to the existing kernel-readahead mechanisms to
> read the binary as efficiently as possible [I know that mmap-like accesses
> like demand paging don't do readahead currently, but it is probably not too
> hard to add].
>
> This bitmap would work as a hint to the readahead predictor. If there is a
> non predicted IO operation it would no throw away this readahead information
> immediately, but only after a (configurable) number of misses occured.
>
> Generating this bitmap is easy using a profiler. For ELF it could be stored
> in a special section of the binary.
Something more general would be:
Given block XXX is accessed right now, what are the chances of
other blocks getting accessed right after this one?
Theoretically you'd need an Nblocks^2 array to hold this information,
but this array will be very sparse, and can be stored much more
efficiently.
Given the block numbers from the blkdev_log, you can write this
application in userspace. The next "excercise for the reader" is to do
something with the statistics and feed it into the kernel read-ahead
processor.
A "ls -l" on my homedir (Yes, I should clean it up) takes 4 seconds.
22k of directory + 450 inodes. having a defragger put them linearly or
doing the read-ahead cleverly will certainly make a big difference.
Roger.
-- If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl | If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 | If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 | If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu