Andi Kleen wrote:
>What I was thinking is just a generic way where an application/kernel module
>can ask the question to a block device:
>
>tell me all areas where I can seek independently.
>
>The return would be a list of (offset, length) pairs where you can seek
>independently. For devices that do not support geometry reporting that is
>only a single pair. That notion can be easily generalized for LVM and RAID
>(they just combine the seekarea lists of the underlying devices, and add
>their own information about device boundaries)
Stupid question time:
If this independent seek stuff makes enough of a performance difference
that we're considering re-ordering disk accesses to take advantage of
it, mightn't there be some way to benchmark the drive to get this info?
I know drive controllers lie about drive geometry (Ben Rafanello at IBM
spent an hour explaining to me why formatting a zip disk on one machine
and trying to read it in another is a cruel and unusual thing to do to a
device driver writer), but couldn't we have some kind of automated
benchmarking program that does a buncha seeks on a given
drive/controller combo and figures out which ones are independent and
which ones aren't, and perhaps does a binary search or whatever for
where the boundaries of these seek ranges are? Then it can save the
info in some kind of config file so it doesn't have to to do the test
again unless you switch hardware.
The FUN part of all this is it could be done in user space, with the
kernel using the extra config file if it's there, and defaulting to one
big seek range (or whatever) if it's not. Sort of on the level of the
hdparm tuning: if you want to do it, you get more speed, if you don't it
still works, and if we ever get Linux preinstalls it's the hardware
manufacturer's job to set this up properly anyway. (In theory, they
wouldn't need to run a benchmark program, they might actually KNOW this
stuff...)
Just a thought...
Rob
-
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