lkml.org 
[lkml]   [1997]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New dcache not using slab allocator?
> Aaron Tiensivu wrote:
> Umm. kmalloc()/kfree() are now built on top of the slab allocator.
> Take a look at linux/mm/slab.c and you will find these nice functions.
> That means nobody has to do anything to take advantage of slab.
> If you have used kmalloc in the kernel, you are already using slab.

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

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans