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 Bonwick07000 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 07000 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.
170
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
