As discussed in earlier sections, the page allocator (in coordination with buddy system) does an efficient job of handling memory allocation requests in multiples of page size. However, most allocation requests initiated by kernel code for its internal use are for smaller blocks (usually less than a page); engaging the page allocator for such allocations results in internal fragmentation, causing wastage of memory. The slab allocator is implemented precisely to address this; it is built on top of the buddy system and is used to allocate small memory blocks, to hold structure objects or data used by kernel services.

Design of the slab allocator is based on an idea of object cache. The concept of an object cache is quite simple: it involves reserving a set of free page frames, dividing and organize them into independent free lists (with each list containing a few free pages) called slab caches, and using each list for allocation of a pool of objects or memory blocks of a fixed size, called a unit. This way, each list is assigned a unique unit size, and would contain a pool of objects or memory blocks of that size. When an allocation request arrives for a block of memory of a given size, the allocator algorithm selects an appropriate slab cache whose unit size is the best fit for the requested size, and returns the address of a free block.

However, at a low level, there is fair bit of complexity involved in terms of initialization and management of slab caches. The algorithm needs to consider various issues such as object tracking, dynamic expansion, and safe reclaim through the shrinker interface. Addressing all these issues and achieving a proper balance between enhanced performance and optimum memory footprint is quite a challenge. We shall explore more on these challenges in subsequent sections, but for now we will continue our discussion with allocator function interfaces.