Messages in this thread | | | Date | Thu, 23 Sep 1999 15:59:36 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [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 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/
| |