48

What are the factors which help to decide the choice of memory allocators in Linux Kernel?

In the present Linux Kernel we have the option of choosing SLAB,SLUB or SLOB. I have read that SLOB is used for Kernel of smaller footprints. But I want to know the factors which help to decide between Slab Allocator and Slub Allocator.

Siddharth
  • 2,046
  • 5
  • 26
  • 41
  • 4
    http://lwn.net/Articles/229984/ in case you haven't seen that –  Mar 18 '13 at 16:29
  • Thanks :) But I have read that article. It gave an insight about Slub but my question was not completely answered with that. I got the answer for it on Quora. I have posted the link down. – Siddharth Mar 19 '13 at 10:32

2 Answers2

59

In the search of answer, I posted the same question on Quora and Robert Love answered it:

I'm assuming you are asking this from the point-of-view of the user of a system, or perhaps someone building a kernel for a particular product. As a kernel developer, you don't care what "slab" allocator is in use; the API is the same.

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 Bonwick1 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 paper2.

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.

Please refer to this link for an original response.

nhed
  • 5,774
  • 3
  • 30
  • 44
Siddharth
  • 2,046
  • 5
  • 26
  • 41
  • 3
    Note that Debian and other distributions have gone back to SLAB because it is faster on multiprocessor systems. See: https://lists.debian.org/debian-kernel/2012/03/msg00944.html – Ariel Dec 01 '14 at 09:54
  • 2
    @Ariel this is interesting, is there any benchmark or something that describes the reason behind this? – dashesy Oct 05 '15 at 18:35
1

SLOB - it's Old.

SLAB - it's Ancient.

SLUB - Use it.

exebook
  • 32,014
  • 33
  • 141
  • 226