Status of the Linux Slab Allocators

Users who compile a Linux kernel have the option to select between three different slab allocators with little to no guidance on which one to use. SLAB, the long-standing favorite of distros that has withstood the test of time, is a complex allocator that performs well on a variety of workloads. SLUB, the kernel's default, has a much simpler design and superior debugging features yet has significant regressions on some benchmarks. And sitting in the background is SLOB for embedded devices and machines which require a very small kernel footprint. The slab allocator is used by the kernel to allocate memory for itself. Thus, the chosen allocator's performance translates to the kernel's performance as a whole and impacts each and every subsystem. SLAB, SLUB, and SLOB each have their own strengths and weaknesses and can cause significant regressions depending on the workload. This talk aims to shed light on those strengths and weaknesses and presents data on which allocator is superior in a variety of different circumstances. This is done by exhaustively comparing the allocators with every major kernel benchmark on several different machine types and memory capacities. Using that data, generalized conclusions can be drawn on the current state of the slab allocators and which one to use depending on the type of workload the kernel will be encountering and what this means for desktop users. In addition to surveying the allocators already merged in Linux, this talk also takes a look at future work by examining recent development in the area: SLUB with queuing, SLQB, and SLAM. The talk culminates in answering the popular question: will we ever have a single slab allocator for Linux and what might that look like? This talk is aimed at everyone interested in kernel development since the interface and performance of slab allocation is used by each and every subsystem. No specialized knowledge of the subsystem's internals is required.