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    [W:0.035 / U:35.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site