Messages in this thread | | | Date | Sat, 20 Mar 1999 14:05:16 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [OFFTOPIC] Re: disk head scheduling |
| |
On Sat, 20 Mar 1999, Tim Smith wrote: > > Linus is almost certainly right that its not worth it--I sure don't want > to put up with around 12 hours of probing at install time to get the real > geometry...and probably another several hours of probing whenever the disk > detects and remaps a bad block.
Note that even if you know exactly what the disk geometry is (and I agree that you can certainly find out - it's just a _lot_ more painful than just asking the drive what the geometry is), that is only a fairly small part of the picture if you actually want to get the perfect disk access patterns.
More important than the geometry by far be be the disk cache algorithms on the controller. Just about all drives do their own level of caching, and the algorithms are not obvious or even the same from manufacturer to another (or even from one disk to another).
For example, of the on-disk RAM, some of the area may be used for other things than caching altogether (block mapping information etc), and the rest may be either one single track buffer (which could or could not depend on the actual disk geometry), or multiple "fixed-sized" disk cache areas, either used in a LRU or FIFO manner, or in some cases a real sector cache.
So when you try to schedule a new request, the best schedule _may_ actually be completely nonobvious simply because it might be close to an old request that still has the track buffer in the on-disk cache.
There was some work done on a "cache-affinity" based request sorting algorithm, and the results were interesting (sadly the code was too specific to a certain disk and controller type to be generally usable in the kernel).
So even if you have a perfect model of the disk itself, if you really want to be good you need to have a model of the disk _electronics_ too.
I much prefer the notion of "perfect is the enemy of good", and I prefer to make something that is simple and _works_, and has no really obvious problems.
Linus
- 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/
| |