Ah, but observe. On my 2.1.47 kernel equipped with dedicated
"dcache", "dname-16", "dname-32", and "dname-64" caches, I get the
following:
% cat /proc/slabinfo
slabinfo - version: 1.0
.
.
dname-64 15 50
dname-32 528 588
dname-16 8630 8636
dentry 9173 9200
.
.
size-512 6 16
size-256 18 42
size-128 55 84
size-64 183 200
size-32 142 168
As you can see, during a modest "cvs release .", the number of dcache
entries isn't hovering around 100. It's grown closer to 10000
entries, so the space "unwasted" by introducing a "dname-16" cache is
tremendous, for some applications.
During low dcache usage, you're quite right: the savings is
negligible, if any.
However, in any case, I'm still convinced that isolating the dcache
stuff in its own set of caches helps on the fragmentation front. The
number of active dcache entries is constantly swinging back and forth
from a minimum of 200-300 to a maximum of several thousand, over and
over again during "normal usage". The potential for fragmentation is
huge, because these dcache entries have (in some cases, much) longer
lifetimes than other kernel objects of similar size.
Stuffing them in their own cache doesn't *solve* this problem, but it
lowers the high water mark for fragmented pages. With dedicated slab
caches for dcache entries, the number of pages "poisoned" by
long-lived dcache information can't exceed the maximum number of pages
worth of dcache information stored at any point in time. Without
dedicated slab caches, the kmalloc caches can be "checkerboarded" with
long-lived dcache objects and short-lived non-dcache objects, and the
number of potentially "poisonable" pages is increased.
Kevin <buhr@stat.wisc.edu>