Quote:
Since implementing a paged and multitasking-capable memory manager is basically the same as implementing an on-disk file system, fragmentation is impossible to avoid in practice.
Of course. I only ask for opinion on the
comparative qualities of the slab and buddy allocator for small allocations.
Some scenarios:
- Allocation owner abruptly leaves the system. Immediately after that a memory demanding action is initiated.
- Requests for one service drop in frequency. Some (significant) period of time passes and a memory demanding action is initiated.
- Some allocations are being attached to durable system objects or object pools, other are attached to in-flight requests. The requests for particular service drop over time, and a memory demanding action is initiated.
My analysis:
- The adjacency of smaller chunks will promote coalescing. The buddy and slab variants use grouping to achieve this. The slab allocator requires many adjacent frees to coalesce the entire slab, which event's probability declines exponentially with the slab size.
- The slab allocator can recover over time if optimized. Usually, the optimization is to choose the most populated slab when providing a new chunk. Busy slabs stay busy and sparsely populated slabs gradually completely evacuate. The buddy allocator simply avoids splitting whenever possible.
- Some allocations stay pinned. This is the eventuality in which I see the slab allocator suffering the most.
In defense of the slab allocator, its header is more compact, its coalescing is faster, and the buddy system tears free chunks on alignment boundaries.
I still wonder. What tilts the scale in favor of the slab allocator over the buddy allocator for heap and pool usage in real systems.