thanks for the feedback! i have trouble with your method for a few
reasons.
first, as dave miller pointed out, i wanted to make all the various hash
init routines look like each other so that eventually someone could split
out the common code, as he suggested. i'm not sure i'm ready to do that,
because i would like to be sure the new logic actually works, first, and
is really generalizable.
so, i don't see any advantage to building special logic into the buffer
hash, especially because it is dwindling in importance. the dentry and
page caches are much more significant to performance.
next, *theoretically* a hash function could approach a scenario where all
the buckets were equally filled, but in practice i don't think that will
ever occur, especially with small tables like these. there will always
be a normal distribution of bucket sizes; that's the nature of statistical
hash functions. the distribution becomes narrow as the size of the table
approaches infinity -- but i don't think we need to worry about that case!
:)
third, why would you want to *vary* the optimal bucket size? that's
always going to be one or two. the hash table's size is probably most
dependent on how much memory is on the machine, anyway.
lastly, i think the kernel would be in deep cookies if *all* available
memory was allocated in the buffer cache. making the table so large is
overkill, IMHO. besides, how can you tell what buffer sizes the system
will need? 2K? 1K? 512 bytes? that will have direct bearing on how
many buffers there are.
so, in summary, i don't think any exact calculation will always generate
an optimal buffer hash table size. guessing is all we can do.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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/