Slab Allocation
The Buddy System is great for managing massive blocks of physical memory, but it has a fatal flaw: severe internal fragmentation. If an operating system needs exactly 45 bytes to create a network socket, the Buddy System might hand it a 64-byte block, wasting 19 bytes. When the OS is creating thousands of these tiny objects every second, that waste adds up rapidly.
Slab Allocation is a specialized memory management technique designed specifically to fix this problem for the OS Kernel.
What is Slab Allocation?
Originally developed for the Solaris operating system and now heavily used in Linux, Slab Allocation acts as an aggressive caching layer built on top of the underlying memory allocator.
The core philosophy is simple: creating, initializing, and destroying complex kernel data structures (like process descriptors, file objects, or network sockets) takes too much CPU time. Instead of throwing these structures away when they are done, Slab Allocation keeps them pre-allocated, initialized, and sitting in a cache, ready to be reused instantly.
The Core Terminology
Slab allocation relies on a strict hierarchy of three components:
- Cache: A dedicated pool of memory that holds EXACTLY one specific type of object. For example, there is a dedicated cache exclusively for "Network Sockets" and a separate cache exclusively for "File Descriptors".
- Slab: One or more contiguous pages of memory assigned to a Cache. A Cache is made up of multiple Slabs.
- Object: The actual data structure itself. A Slab is sliced perfectly into identically sized Objects.
The Three States of a Slab
To manage allocations efficiently, the OS tracks every Slab and categorizes it into one of three states:
- Full: Every single object inside this slab is currently being used.
- Partial: Some objects are in use, but some are free. (The OS always tries to allocate from a Partial slab first to keep memory tightly packed).
- Empty: Every object in this slab is free. (If the system runs low on overall memory, the OS can destroy an Empty slab and return its pages to the Buddy System).
How Allocation Works
Step 1: A program opens a file. The OS needs a "File Descriptor" object.
Step 2: The OS goes directly to the File Descriptor Cache.
Step 3: It searches for a Partial Slab.
Step 4: It finds a free Object in that slab and hands it over immediately. The object is already initialized!
Step 5: When the program closes the file, the OS does NOT destroy the memory. It simply marks that Object as "free" again in the slab, waiting for the next request.Advantages of Slab Allocation
| Advantage | Explanation |
|---|---|
| Zero Internal Fragmentation | Because a cache is designed for one specific type of object, the slab is cut exactly to that object's byte size. Nothing is wasted. |
| Blazing Fast Allocation | Objects are pre-allocated and pre-initialized. The OS just hands over a pointer rather than building the structure from scratch. |
| Hardware Cache Efficiency | By packing identical objects tightly together in physical memory, it greatly improves the hit rate of the CPU's L1/L2 hardware caches. |
Summary
Slab allocation is not meant for user programs; it is a highly optimized tool for the Operating System Kernel. By grouping identical structures into Caches and Slabs, it completely eliminates internal fragmentation for tiny objects and provides lightning-fast performance by endlessly reusing pre-initialized memory.