SLAB memory management

The slab allocator is an abstraction layer to make easier allocation of numerous objects of a same type. The interface offers the function

struct kmem_cache * kmem_cache_create(const char *name,
    size_t size, size_t align, unsigned long flags,
    void (*ctor)(void*));

This function creates a new slab allocator that will be able to handle allocation of size-bytes long objects. If the creation is successful, you get your pointer to the related struct kmem_cache. This structures holds information about the slabs it manages.

As it is implied on the Wikipedia description, the purpose of such an extra layer is to prevent memory fragmentation issues that could happen if the memory allocation was made in a simple and intuitive manner. To do so, it introduces the notion of slab through the following data structure :

struct slab {
    struct list_head list; /* embedded list structure */
    unsigned long colouroff;
    void *s_mem; /* first object in the slab */
    unsigned int inuse; /* allocated objects in the slab */
    kmem_bufctl_t free; /* first free object (if any) */
};

Thus, the kmem_cache object holds 3 lists of its slabs, gathered in 3 flavours :

• Empty slabs : these slabs do not contain an in-use object.
• Partial slabs : these slabs contain objects currently used but there is still memory area that can hold new objects.
• Full slabs : these slabs contains objects being used and cannot host new objects (full ...).

When requesting an object through the slab allocator, it will try to get the required memory area within a partial slab, if it cannot, it will get it from an empty slab.

If you are eager to collect more information about this, you should take a look at Robert Love's Linux Kernel Development

I may be too late to answer this, but this may help others as well. As I see from Understanding Linux Virtual Memory Manager, having slabs has three major benefits.

1. Reducing internal fragmentation caused by buddy system. Because we have caches that best suits smaller objects.
2. Better hardware cache usage - by aligining objects to start at different offsets in different slabs so that interference between cache lines can be reduced. This is based on assumption that we have physically indexed cache.
3. A slab is primary unit in cache, which is acquired/relinquished at once. This causes reduction in external fragmentation as well.

See section 3.2 from The Slab Allocator: An Object Caching Kernel memory Allocator (1994).