Messages in this thread |  | | | Subject | Re: New dcache not using slab allocator? | | From | (Kevin Buhr) | | Date | 06 Aug 1997 13:14:19 -0500 |
| |
R.E.Wolff@BitWizard.nl (Rogier Wolff) writes: > > For example suppose there are only 100 dcache entries: > 8,16 and 32 byte entries: total 1 page of 32 byte slots.
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>
|  |