[lkml]   [1999]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] hashtable sizes for icache and dcache

    On Thu, 23 Sep 1999, Andrea Arcangeli wrote:

    > >this patch alone indeed is just fixing the symptoms. If such a patch makes
    > You don't understand the difference between fixing the symptom and fixing
    > the cause of a problem.

    what i and (Rik? he has sent the mail privately to you i
    think) ment: fixing the hash bit-order alone is just the symptom of the
    real problem. The real problem is that boxes with different memory sizes
    have fundamntally different 'optimal hashsize'.

    Historically, when the dcache/inode/buffer cache/page cache/tcp/etc hashes
    were developed only one hashsize was picked, which was (hopefully) the
    optimum for the memory size the original developer used. This worked
    pretty well for the 4M-32M RAM range. In the last 2 years or so RAM prices
    finally started to converge to their production costs, and bigger RAM
    boxes started to appear. The symptom: (which i think Leonard Zubkoff or
    Doug Ledford noticed more than a year ago) is that on big memory boxes
    (512M, 1G, 2G RAM boxes) we waste many cycles on cache misses and list

    the wrong solution: to change HASH_BITS ad-hoc for one specific (big)
    memory size. This slows down the 4M-32M RAM range (both through wasting
    memory, and through having less cache-locality in that huge hashtable).
    Those small-memory boxes are very important to Linux as well.

    the real solution: to put an architecture in place that makes it easy to
    boot-time tune the hash, depending on RAM-size. Some parts of the code
    (buffer-cache) did this already, but we clearly needed to do this at once,
    and in the same way. This is David's (Chuk's) patch. Actually it turns out
    that hashsize-heuristics are very subsystem-dependent, so David's patch
    does hash sizing in every place differently, but still we needed some
    central patch that does it in the same style in every important place, and
    the few remaining places can now tune up to this methodology. Actually
    providing such a complete patch is much harder than it looks like and
    needs broad understanding of all subsystems and needs careful tuning,
    probably this is the reason why it took a year or so for someone to take
    up the issue :)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.019 / U:3.388 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site