Introduction
Modern operating systems continuously allocate and deallocate memory for:
Processes
Threads
Inodes
File descriptors
Process control blocks
Network buffers
Kernel data structures
Kernel memory allocation is especially challenging because:
Allocation happens very frequently
Performance requirements are strict
Fragmentation must be minimized
Memory efficiency is critical
Traditional allocation systems like:
First-fit
Best-fit
Buddy allocation
work well for general memory management, but kernel objects are often:
Repeatedly created and destroyed
Similar in size
Frequently reused
Repeated allocation/deallocation creates:
Overhead
Fragmentation
Performance inefficiency
To solve this, operating systems introduced:
Slab Allocation
Slab allocation is one of the most important kernel memory management techniques used in modern operating systems, especially:
Linux
It improves:
Allocation speed
Memory reuse
Cache efficiency
Fragmentation control
What is Slab Allocation?
Slab allocation is a kernel memory management technique that allocates memory using caches of pre-initialized objects.
Instead of allocating raw memory repeatedly:
Frequently used kernel objects are reused from object caches.
Core Idea
Frequently used kernel objects are stored in reusable memory caches
Important Insight
Slab allocation improves performance by reusing preallocated kernel objects
Why Slab Allocation is Necessary
Suppose operating system repeatedly creates:
Process descriptors
File objects
Inodes
Without caching:
Frequent allocation/deallocation expensive
Problems include:
Fragmentation
Slow allocation
Initialization overhead
Slab allocation solves this by:
Reusing already initialized objects
Relationship with Buddy System
Very important concept.
Buddy System
Allocates:
Raw physical memory pages
Slab Allocator
Uses memory provided by:
Buddy allocator
then organizes it efficiently into:
Kernel object caches
Important Insight
The buddy system allocates pages, while slab allocation manages kernel objects inside those pages
Basic Terminology in Slab Allocation
Cache
Stores objects of same type.
Example:
Process descriptor cache
Inode cache
Slab
Collection of memory blocks containing objects.
Object
Actual kernel data structure.
Example:
inode
task_struct
file object
Free Object
Unused reusable object.
Used Object
Currently allocated object.
Slab Structure
A slab contains:
Multiple objects of same type
Example:
Slab for inode objects
may contain:
Many inode structures
Important Insight
Each slab stores objects belonging to a single object type
How Slab Allocation Works
Step 1: Cache Creation
Kernel creates object cache.
Example:
Cache for process descriptors
Step 2: Slab Allocation
Allocator requests pages from:
Buddy system
Step 3: Object Initialization
Objects preinitialized.
Step 4: Allocation Request
Kernel requests object.
Allocator:
Returns free object from cache
Step 5: Object Release
Object returned to cache instead of immediate destruction.
Workflow Visualization
Buddy System → Slab Pages → Object Cache → Fast Allocation
Types of Slabs
Slab allocator maintains slabs in different states.
1. Full Slab
All objects allocated.
2. Partial Slab
Some objects free.
3. Empty Slab
No objects allocated.
Advantages of Slab States
Allocator quickly finds:
Available objects
without scanning entire memory.
Object Reuse in Slab Allocation
Suppose process terminates.
Its process descriptor:
Returned to slab cache
Later:
Reused directly
Advantages:
Faster allocation
Reduced initialization cost
Kernel Objects Commonly Using Slabs
Examples:
Process descriptors
File descriptors
Network buffers
Inodes
Dentries
Memory descriptors
Example in Linux
Linux caches:
task_struct
inode_cache
dentry_cache
Internal Fragmentation in Slab Allocation
Slab allocation minimizes:
External fragmentation
but some internal fragmentation may remain.
Reason:
Slabs contain fixed-size objects
Cache Coloring
Advanced slab optimization.
Purpose:
Improve CPU cache utilization
Technique:
Objects positioned differently in cache lines
Advantages:
Reduced cache conflicts
Important Insight
Slab allocation improves both memory efficiency and CPU cache performance
Constructor and Destructor Functions
Slab allocators may use:
Constructors
Destructors
Constructor
Initializes object when slab created.
Destructor
Cleans object when slab destroyed.
Advantages:
Reduced repeated initialization overhead
Slab Allocation vs Traditional Allocation
| Feature | Traditional Allocation | Slab Allocation |
|---|---|---|
| Allocation speed | Slower | Faster |
| Object reuse | No | Yes |
| Fragmentation | Higher | Lower |
| Cache performance | Lower | Better |
| Kernel optimization | Limited | High |
Slab Allocation and Fragmentation
External Fragmentation
Reduced significantly.
Reason:
Objects grouped efficiently.
Internal Fragmentation
Still possible inside slabs.
Example
Unused object slots inside partially filled slab.
Memory Allocation Path in Linux
Simplified Linux allocation flow:
Buddy Allocator → Slab Allocator → Kernel Objects
SLAB, SLUB, and SLOB Allocators
Linux evolved multiple slab allocator versions.
1. SLAB
Original Linux slab allocator.
2. SLUB
Modern default Linux allocator.
Simpler and faster.
3. SLOB
Designed for:
Embedded systems
Small memory devices
Important Insight
Modern Linux systems primarily use the SLUB allocator for improved scalability and performance
SLUB Allocator
SLUB simplifies:
Queue management
Metadata handling
Advantages:
Better multicore scalability
Lower overhead
NUMA-Aware Slab Allocation
Modern systems use:
NUMA-aware slab allocation
Advantages:
Local memory access
Better scalability
Per-CPU Object Caches
Modern slab allocators maintain:
Per-CPU caches
Advantages:
Reduced locking
Better concurrency
Faster allocations
Synchronization in Slab Allocation
Kernel memory allocation highly concurrent.
Slab allocators use:
Spinlocks
Per-CPU caches
Lock reduction techniques
to support:
Multicore systems
Advantages of Slab Allocation
1. Fast Allocation
Objects reused efficiently.
2. Reduced Fragmentation
Memory organized better.
3. Better Cache Locality
Improves CPU performance.
4. Lower Initialization Cost
Objects preinitialized.
5. Scalable
Works well in multicore systems.
Disadvantages of Slab Allocation
1. Complexity
More complicated than simple allocators.
2. Memory Overhead
Caches consume memory.
3. Wasted Space
Unused objects may remain cached.
4. Difficult Debugging
Kernel allocators highly complex.
Real-World Example
Suppose Linux kernel handles:
Thousands of network packets
Each packet requires:
Network buffer object
Without slab allocation:
Frequent allocation overhead huge
With slab allocator:
Buffers reused
Fast allocation achieved
Cache locality improved
Throughput increased
Slab Allocation and Performance
Slab allocation improves:
Kernel responsiveness
System throughput
Multicore scalability
Especially important for:
Servers
Databases
Networking systems