lkml.org 
[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.126 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site