As early as Linux version 2.6.23, the SLUB memory allocator became the default in the Linux kernel. The kernel will fallback to using the SLOB allocator only if the CONFIG_SLAB flag is disabled. According to foreign media Phoronix, Linux kernel developers are considering deprecating and eventually removing the SLOB memory allocator.

The SLOB (simple list of blocks) allocator is one of three memory allocators available in the Linux kernel. The other two are SLAB (slab allocator) and SLUB (the unqueued slab allocator).

SLOB allocators are designed to require very little memory to implement and manage, and are often used in small systems such as embedded systems.

Vlastimil Babka from SUSE sent a kernel email to deprecate and delete SLOB. The email mentioned that the three memory allocators of SLOB and SLAB are maintained at the same time, which causes too much burden on the kernel developers. In addition, only some functions of SLOB are compatible with a subset of allocators, which also causes the development of SLOB functions to spend more effort, indirectly blocking API improvements.

But the biggest problem is that the scope of application of SLOB is too small. Its original design is mainly an allocator for small memory devices, and it strives for the smallest memory footprint by processing all objects together. This also results in its high CPU performance cost (locking, lack of percpu cache, searching for free space, etc…) and it can easily be heavily impacted by external fragmentation, causing performance issues. Now the memory is worthless, the minimum RAM of hardware devices has to be 128 MB, and SLOB has already passed the era of power.

What Vlastimil mentioned in the email is to give up the two memory allocators SLOB and SLAB, leaving only SLUB. So far, other upstream developers are in favor of deprecating and removing SLOBs, and removing SLABs may take more time. In the next few releases, SLOBs will be marked broken or declared deprecated and eventually stripped from the kernel source tree.