Briefly about SLAB, SLOB and SLYB in Linux

Hello! When it comes to dynamic memory management in Linux, we are dealing with several different approaches, each with their own pros and cons.

In this article we will analyze three kernel memory allocators: SLAB, SLOB, and SLUB.

Why do we need slab managers at all?

The Linux kernel handles many objects that take up memory, but their size can vary greatly. Allocating memory through the normal heap mechanism (like malloc in user space) would be too expensive and lead to significant fragmentation. Slab managers were designed to better manage memory, minimize fragmentation, and speed up work with small objects that are often created and destroyed by the kernel.

Basic idea: slab as a container

SLAB is based on the concept of caches that store objects of a certain size. These objects are located in memory blocks called slabs. Each slab contains several objects of the same type and can be in one of three states:

1. Empty – all objects are free.

2. Partially filled — some objects are occupied.

3. Fully filled — all objects are occupied.

When the kernel needs an object, it first tries to find a free object in partially filled slabs. If there are no such objects, a new slab is allocated.

Slab structure

Each slab consists of several memory pages (4 KB by default), which are divided into small pieces (objects). When an object is deallocated, it is not physically deleted, but is returned to slab so that it can be reused. This reduces the overhead of memory allocation and deallocation.

struct kmem_cache {
    unsigned int object_size;    // Размер объекта
    unsigned int num;            // Количество объектов в slab'е
    struct list_head slabs_full, slabs_partial, slabs_empty;  // Списки slab'ов
};

SLAB uses three lists:

• slabs_full — all objects in these slabs are occupied.

• slabs_partial — slabs that contain free objects.

• slabs_empty — empty slabs that can be used for new objects.

Let's say the kernel needs an object that is 32 bytes in size. If there is free space in partially filled slabs, it is allocated. If there is no space, a new slab is created. This is what it looks like:

struct kmem_cache *my_cache;
my_cache = kmem_cache_create("my_cache", sizeof(struct my_struct), 0, SLAB_HWCACHE_ALIGN, NULL);
void *obj = kmem_cache_alloc(my_cache, GFP_KERNEL);
// используем объект
kmem_cache_free(my_cache, obj); // возвращаем его в кэш

SLAB is well suited for server systems with a large number of parallel requests.

How does SLOB work?

SLOB is a super minimalistic allocator, which, unlike SLAB, is focused on minimal overhead costs And maximum memory savings. It resembles the operation of a standard heap, like malloc in user space. Internally, SLOB operates on small blocks of memory, making it very simple and efficient for resource-constrained devices.

How does this work?

1. Free Blocks (Free List). SLOB does not have caches like SLAB, and objects are allocated dynamically from memory blocks. The allocator stores a list of free blocks from which objects are allocated. When an object is freed, it is returned to the free list, which makes the algorithm simple but leads to fragmentation.

2. Memory allocation. SLOB works like a simple heap, allocating exactly as much memory as needed. If fragmentation is too high and a suitable block cannot be found, a new one is allocated.

3. Memory saving. Because SLOB allocates exactly as much memory as needed without using large slabs, it is optimal for systems where saving every byte is important.

Example of simple memory allocation using SLOB:

void *data = slob_alloc(128);
if (data) {
    // Работаем с выделенной памятью
    slob_free(data);  // Освобождаем память
}

SLOB allocates the minimum block required for an object

What is the difference between SLAB and SLOB?

SLUB

SLUB uses a simplified structure compared to SLAB. It does not support concepts such as an object cache, nor does it store metadata about each object in a separate structure. Instead SLUB stores free memory blocks directly inside slabs.

Each processor has its own active slab, which optimizes the performance of multiprocessor systems and minimizes delays in memory allocation.

Example structure in SLUB:

struct kmem_cache_cpu {
    void **freelist;     // Список свободных блоков памяти
    struct page *page;   // Текущая страница slab'а
};

In this example freelist is a pointer to free blocks of memory that can be quickly allocated for new objects. Instead of creating complex caches like SLAB, SLUB simply stores pointers to free objects directly in slabs.

What to choose

Dynamic memory management in Linux is implemented through several allocators, each of which solves its own problems. SLAB provides high performance by caching objects and minimizing fragmentation, which is ideal for server systems with high load. SLOB focuses on memory savings and minimal overhead, making it the best choice for resource-constrained embedded devices. SLUB is a simplified and improved version of SLAB, giving faster operation, especially on multiprocessor systems.

You can learn professional configuration selection, process management, security, deployment, configuration and maintenance of networks at online course “Administrator Linux. Professional” under the guidance of expert practitioners.