Slab Allocation

Generally, I will be referring to the slab allocator implementation of the SunOS 5.4 kernel memory allocator.
Description: The slab allocator is simply a kernel memory allocator. Slab caches are created and each slab cache can contain one or more slabs of objects of the same type. Basically, each slab cache is a linked list of slabs and each slab is an array of objects. Where an object can be an inode, a semaphore, etc...In object-oriented terminology slab cache is a factory for a specific type of object.
The memory allocator's job is to build slab caches. During start-up a client will request creation of slab caches for various objects. At this time the client provides parameters for the construction of the slab cache. These parameters are the size of the object, its alignment and its constructor and destructor.This slab cache then creates a slab of objects as the client requests. The slab keeps a reference count of how many of its objects are being used. When the client is done it simply returns the object to the slab cache in its constructed state. When all slabs in the slab cache are full and another object is requested the slab cache can add new slabs. As a result of memory pressure, the system may request the slab cache to shrink by relinquishing those slabs with a reference count of zero.


Object caching allows the allocator to adapt to its clients requests, because the client is giving the allocator its exact specifications. Basically the idea is that more time is wasted constructing and destroying objects than actually allocating and deallocating memory for these objects. By object caching, the overhead of constructing and destroying an object will only happen once, the first time it is used.

Another advantage of object caching is, since all objects in a slab are of the same type their lifetimes tend to be similar this reduces external fragmentation. Internal fragmentation is reduced because the only unused portion will be what is left after objects are allocated; therefore, ignoring alignment, internal fragmentation will be less than 1/n, where n is the number of objects in the slab.

An interesting technique the slab allocator employs is slab coloring. The idea behind slab coloring is, objects should be distributed evenly throughout the hardware cache which results in improved cache utilization. How this works is, when a new slab is created its objects will have a different offset from the beginning of the slab. This offset determines the color of the object (i.e. which cache line it is mapped to).


Sources I used and implementations of slab allocation can be found at:
The Slab Allocator: An Object-Caching Kernel Memory Allocator
Implementation: Linux: slab.c
Back to page one.