Messages in this thread | | | Subject | Re: elevator algorithm bug in ll_rw_blk.c | Date | Tue, 17 Nov 1998 09:20:51 +0100 | From | Helge Hafting <> |
| |
> Thanks to several who gave me an education about true disk geometry vs > reported. I do have a follow-on question. The hdparm command for > example can determine the drive model. Given that, and data sheets, > shouldn't a hd driver be able to choose from a database of tuning > parameters to optimize drive access? The fallback could always be the > simpler, straight-forward approach taken now. This would require either Who should make that base and keep it updated? With the tens of thousands of disks available and new models coming in - the fallback would be used a lot. > manufacturer's data put into the table, or probably even better, timing > based on probing of the drive model. Do drives vary much any more > between copies of the same model, so would an inidividual drive need to > be optimized, or just a model? A model satisfies some spec. Nothing stops the manufacturers from continuing a popular "model" with a different number of platters in order to save money when technology changes. Bugfixes to the on-drive cache algorithm could affect timing a lot too. So I thing you'll have to prober individual drives. Even upgrading your cpu can affect timing, as a faster cpu have time for more request sorting during a seek. > > Would this be worth the effort? Would we get, say double the read speed > in general-purpose access, or perhaps in specialized efforts, such as > large database access? You would see improvement yes - but probably nothing impressive. Perhaps 2%-5%, and this is why it isn't really worth it. Seeking from end to the disk to the beginning is slower than a shorter seek, but not by much. Moving n tracks idoes not take n times the time for moving one track, the heads typically move with constant acceleration/deceleration. And this long seek doesn't happen often with the current algorithm either. In short, there isn't much to save.
Helge Hafting
- 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/
| |