Slab allocator
Slab Allocator is a cache management structure for efficient use of kernel memory. It was designed by Jeff Bonwick of Sun Microsystems, for SunOS. It is also a part of the basic Linux kernel memory management system. It is targeted for use of many small pieces of memory chunks. By managing small memory chunks in the units called slabs, this mechanism enables lower fragmentation, fast allocation, and reclaming memory.
Caches
Caches are a per-type structure that is allocated, which controls allocation and deallocation of slabs. There are two functions that are available, one to allocate and one to deallocate chunks of memory. Caches can contain many slabs, which are allocated by the cache. The cache maintains lists of allocated and partially allocated slabs, as well as a list of free slabs. Once a slab has been initialized, it is always either in-use or constructed and ready for use.
Slabs
A slab is the amount that a cache can grow or shrink by. It represents one memory allocation to the cache from the machine, and whose size is customarily a multiple of the page size. A slab must contain a list of free buffers (or bufctls), as well as a list of the bufctls that have been allocated (in the case of a large slab size)
Large Slabs
These are for caches that store objects that are not less than 1/8 of the page size for a given machine. The reason for the large slabs having a different layout from the small slabs is that it allows large slabs to pack better into page-size units, which helps with fragmentation. The slab contains a list of bufctls, which are simply controllers for each buffer that can be allocated (a buffer is the memory that the user of a slab allocator would use)
Small Slabs
The small pages contani objects that are smaller than 1/8 the size of a page on the machine. These small slabs need to be optimized further from the logical 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 instead use the buffers themselves to retain the free list links. This allows the small slab's bufctl to be bypassed.
Bufctls
...
Performance
...