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:4.867 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site