However, you can do a lot better than that. Directly using a SLAB
for dcache objects gives you the following advantages:
- faster allocation: kmalloc goes through a list of slabs to find one
of the right size. This is overhead, as the right size is known
at compile time.
- less memory overhead: kmalloc's list of pools is structured in powers
of two (32, 64, 128...). If you allocate via kmalloc and don't exactly
fit into one of the slabs, you lose some bytes per object.
So I really don't see why there is no dedicated pool for dcache entries.
Of course, the file name associated with a dentry is variable-sized,
and should be managed using kmalloc.
For inodes, it is different: They are already allocated from a pool
(see inode.c:grow_inodes). Somebody with a good understanding of SLAB
please comment whether SLAB is more efficient than that (by whatever
measure). One advantage of using SLAB would be that inodes allocated
that way are never returned to the system. A slab might give better
behaviour in low-memory situations.
Regards,
Martin