lkml.org 
[lkml]   [2006]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [MODSLAB 0/7] A modular slab allocator V1
    On Tue, Aug 15, 2006 at 07:22:38PM -0700, Christoph Lameter wrote:
    > Some of the other issues in the slab layer are also addressed here:
    >
    > 1. shrink_slab takes a function to move object. Using that
    > function slabs can be defragmented to ease slab reclaim.
    >
    > 2. Bootstrap occurs through dynamic slab creation.
    >
    > 3. New slabs that are created can be merged into the kmalloc array
    > if it is detected that they match. This decreases the number of caches
    > and benefits cache use.

    While this will be good for reducing fragmentation, one important
    thing is needed here for tracking down leaks and slab corruptions -
    the ability to split the caches back out into individual slabs.
    Maybe a boot parameter would be useful here - that way it is easy to
    determine which type of slab object is causing the problems without
    needing the end user to run special kernels.

    Also, some slab users probably want their own pool of objects that
    nobody else can use - mempools are a good example of this - so there
    needs to a way of indicating slabs should not be merged into the
    kmalloc array.

    Cheers,

    Dave.
    --
    Dave Chinner
    Principal Engineer
    SGI Australian Software Group
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-08-16 10:15    [W:3.256 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site