The slab allocators of past, present, and future
summary
A concise history of Linux slab allocators traces slub default since 2007, the original slab, and slop for tiny systems, explaining why three implementations coexist. Measured differences: slub gives best general performance but lacks a per‑CPU free cache that hurts cross‑CPU frees for networking, while slop packs objects to save memory and needs a size header to support kfree causing large overhead (kfree vs kmem_cache size header). Attempts to merge (slqb, SLEB) stall; proposals include adding optional per‑cache fast free paths or generalizing per‑subsystem caches like io_uring and SKB.
AI-written summary · about
chapters (7)
- 0:00Introduction and motivation
- 0:48Historical evolution
- 7:51Development of slub and slqb
- 11:38Current state of allocators
- 12:58Challenges of multiple systems
- 17:14Addressing performance issues
- 22:49Future directions and closing
related talks
51mReducing the Kernel's Slab Allocators: Progress Report
01h 31mSLUB Internals for Exploit Developers
05mSlab allocators
44mHands Off and Putting SLAB/SLUB Feng Shui in a Blackbox
41mLies Programmers Believe about Memory
19mLLFree: Scalable and Optionally-Persistent Page-Frame Allocation
21mCgroup Slab Memory Controller and Time Namespace
42mAllocators for Compressed Pages: In-depth Comparison with z3fold in Focus