> >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 kernel@kvack.org (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
walking.
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 :)
Ingo
-
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/