>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.
That's perfectly true (mostly in 2.3.7 :). (except while using block
device from /dev and we still want to be fast in such case).
>third, why would you want to *vary* the optimal bucket size? that's
I don't want to vary it infact (it's not a config kernel option).
>always going to be one or two. the hash table's size is probably most
Agreed. It's one right now.
>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.
An exact calculation make more sense to me though (that's why I did it). I
don't think we need a MBPB < 1, see also the interesting Peter's results
(btw and the real MBPB will be just lower than 1 since after the exact
hash-size I enlarge the bufsize to reach the first power of 2 and I
suppose that all the kernel memory will be available for buffers while
only a part of it will be available).
Andrea Arcangeli
-
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/