Re: [MODSLAB 0/7] A modular slab allocator V1

[David Chinner <dgc@sgi.com>]

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/