Linux Kernel: What are the factors in choosing among the different memory allocators in the Linux kernel?
First, “slab” has become a generic name referring to a memory allocation strategy employing an object cache, enabling efficient allocation and deallocation of kernel objects. It was first documented by Sun engineer Jeff Bonwick[1] and implemented in the Solaris 2.4 kernel.
Linux currently offers three choices for its “slab” allocator:
Slab is the original, based on Bonwick’s seminal paper and available since Linux kernel version 2.2. It is a faithful implementation of Bonwick’s proposal, augmented by the multiprocessor changes described in Bonwick’s follow-up paper[2].
Slub is the next-generation replacement memory allocator, which has been the default in the Linux kernel since 2.6.23. It continues to employ the basic “slab” model, but fixes several deficiencies in Slab’s design, particularly around systems with large numbers of processors. Slub is simpler than Slab.
SLOB (Simple List Of Blocks) is a memory allocator optimized for embedded systems with very little memory—on the order of megabytes. It applies a very simple first-fit algorithm on a list of blocks, not unlike the old K&R-style heap allocator. In eliminating nearly all of the overhad from the memory allocator, SLOB is a good fit for systems under extreme memory constraints, but it offers none of the benefits described in [1] and can suffer from pathological fragmentation.
What should you use? Slub, unless you are building a kernel for an embedded device with limited in memory. In that case, I would benchmark Slub versus SLOB and see what works best for your workload. There is no reason to use Slab; it will likely be removed from future Linux kernel releases.
[1] Page on Usenix.org [2] Page on Usenix.org http://www.quora.com/Linux-Kernel/What-are-the-factors-in-choosing-among-the-different-memory-allocators-in-the-Linux-kernel
#linux #memory #slub #slab #slob #optimization #jeff-bonwick #kernel #algorithm