layout, by avoiding using bufctls (which would be just as large as the data itself and cause memory usage to be much greater). A small slab is exactly one page, and has a defined structure that allows bufctls to be avoided. The last part of the page contains the 'slab header', which is the information needed to retain the slab. Starting at the first address of that page, there are as many buffers as can be allocated without running into the slab header at the end of the page. Instead of using bufctls, we use the buffers themselves to retain the free list links. This allows the small slab's bufctl to be bypassed. Systems using slab allocation AmigaOS (introduced in AmigaOS 4) DragonFly BSD (introduced in release 1.0) FreeBSD (introduced in 5.0) GNU Mach Haiku (introduced in alpha 2) Horizon (Nintendo Switch microkernel) HP-UX (introduced in 11i) Linux (introduced in kernel 2.2, it's now one of three memory allocator implementations together with SLOB and SLUB. The three allocators provides a kind of front-end to the zoned buddy allocator for those sections of the kernel that require more flexible memory allocation than the standard 4KB page size). NetBSD (introduced in 4.0) Solaris (introduced in 2.4) The Perl 5 compiler uses a slab allocator for internal memory management Memcached uses slab allocation for memory management illumos See also Fixed-size blocks allocation Memory pool SLOB SLUB Notes External links FreeBSD uma(9) manual page The SLUB allocator comment about management of slabs in Linux by two different allocators: SLUB allocator and SLAB allocator Memory Compaction v7 (a Linux patch set from Mel Gorman dealing with SLAB fragmentation and compaction issues, 2 April 2010) Detecting kernel memory leaks Jonathan Corbet, Linux Weekly News, 2006; includes user comments on garbage collection Linux performance: is Linux becoming just too slow and bloated? On SLAB and SLUB. Free software magazine 2010. Memory management algorithms