A Quick History of the Linux Kernel Slab Allocator

The original linux kernel slab allocator, known simply as SLAB, was inspired by an object-caching design first published for Sun’s SunOS kernel in the 1990s. The idea was straightforward: rather than repeatedly constructing and destroying kernel objects of the same type, keep a cache of pre-initialised objects ready to hand out and take back. This dramatically reduced the CPU cost of frequent allocate/free cycles for structures the kernel uses constantly, such as inodes and task descriptors.

Over time two more implementations joined SLAB in the kernel tree:

• SLOB (Simple List Of Blocks) — a deliberately minimal allocator aimed at very small, memory-constrained systems, trading performance and scalability for a tiny code and memory footprint.
• SLUB (the “unqueued” slab allocator) — introduced years later as a simplification of SLAB, dropping SLAB’s per-CPU/per-node queueing machinery in favour of simpler per-CPU slabs, less metadata overhead, and better diagnostics.

SLAB vs SLUB vs SLOB: Side-by-Side Comparison

Why Was SLOB Removed First?

SLOB traded away almost every optimisation the other two allocators relied on in exchange for a very small memory footprint, which made sense in the mid-2000s when “embedded” often meant single-digit megabytes of RAM. As typical embedded RAM budgets grew into the hundreds of megabytes or gigabytes, SLOB’s poor scalability and lack of support for newer kernel guarantees (such as being able to call a single generic kfree() on any slab-allocated object) made it harder to justify keeping around. It was removed from the kernel tree in the 6.4 release.

Why Was SLAB Removed Next?

SLAB was not bad — it had served as the default for well over a decade — but maintaining two general-purpose allocators side by side meant kernel developers had to duplicate features like memory control group accounting in both, test both, and avoid regressions in both. Once major users of SLAB migrated their workloads to SLUB and reported acceptable or better results, the kernel memory-management maintainers moved to deprecate SLAB in kernel 6.5 and remove it entirely in kernel 6.8, leaving SLUB as the kernel’s single linux kernel slab allocator.

How SLUB Organises Memory: Caches, Slabs, and Objects

Understanding SLUB’s structure makes the rest of the free linux kernel development course memory-management material click into place. SLUB works with a simple three-level hierarchy:

Each cache groups objects of a particular size or type. A cache is backed by one or more slabs, and each slab is a chunk of memory (one or more contiguous pages, obtained from the page allocator) sliced into fixed-size objects. Free objects within a slab are tracked with a simple in-place freelist, so allocating from a partially-used slab is typically just a pointer update, with no searching and no coalescing required. That gives allocation and free operations very predictable latency, which is one reason slab-based allocation suits both general-purpose and latency-sensitive kernel code.

Checking Which Allocator Your Kernel Uses Today

You can confirm your own system’s configuration in seconds. Run these commands as part of your hands-on practice for this free linux kernel development course:

zcat /proc/config.gz 2>/dev/null | grep -i slab
grep -i slub /boot/config-$(uname -r) 2>/dev/null
cat /proc/slabinfo | head -20

On any kernel from the 6.8 series onward you will simply find SLUB references and no working SLAB or SLOB build option at all — the config symbols for the older two no longer exist to select.

CONFIG_SLUB_TINY: Bringing Small-System Support to SLUB

With SLOB gone, small and memory-constrained systems still needed a way to keep SLUB’s memory footprint down. The kernel addressed this with the CONFIG_SLUB_TINY option, which trims SLUB’s per-CPU caching and other memory-hungry optimisations to bring its footprint closer to what SLOB used to offer, without maintaining an entirely separate allocator implementation. This is a good example of consolidating functionality instead of duplicating it — a recurring theme in modern kernel memory management.

Real-World Use Case: Why This History Matters for Driver Authors

If you maintain an out-of-tree driver or module that references CONFIG_SLAB in build scripts, conditional compilation, or documentation, that code will silently stop making sense on any kernel from the 6.8 series onward, since the symbol no longer exists. This kind of stale assumption is exactly why keeping your mental model current matters as much as knowing the APIs — a running theme throughout this free embedded systems course.

Common Mistakes and Troubleshooting Tips

Best Practices

• Always verify allocator-related kernel config assumptions against the actual kernel version you are targeting.
• Use /proc/slabinfo during driver bring-up to sanity-check cache behaviour, not just theoretical understanding.
• On memory-constrained embedded targets, evaluate CONFIG_SLUB_TINY before assuming you need custom allocation logic.
• When reading older Linux kernel books or courses, treat any mention of “choosing between SLAB, SLUB, and SLOB” as historical context rather than a decision you can still make.

Summary and Key Takeaways

• The Linux kernel once shipped three slab allocator implementations: SLAB, SLUB, and SLOB.
• SLOB was removed in kernel 6.4; SLAB was deprecated in 6.5 and fully removed in 6.8.
• SLUB is now the sole general-purpose slab allocator in mainline Linux.
• SLUB organises memory as caches, made of slabs, made of fixed-size objects with an in-place freelist.
• CONFIG_SLUB_TINY lets small systems shrink SLUB’s footprint instead of relying on the now-removed SLOB.

Conclusion

The consolidation from three slab allocators down to one is a good reminder that kernel internals keep evolving even when the public-facing kmalloc() API stays stable. Knowing that SLUB is now the sole linux kernel slab allocator, understanding why SLAB and SLOB were retired, and knowing where CONFIG_SLUB_TINY fits in gives you an accurate, current mental model — exactly the goal of this free linux kernel development course and free linux device drivers course.