Messages in this thread | | | Date | Sun, 30 Jul 2000 11:47:25 -0400 | From | Rob Landley <> | Subject | Re: ORBS Elevator - userspace benchmark saving config file perhaps? |
| |
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/
| |