In this lesson, you will learn how to monitor kernel slab usage to identify memory leaks caused by malfunctioning kernel subsystems.
Understanding the Slab Allocator
The kernel slab allocator (SLUB or SLAB) manages memory for kernel objects of specific sizes, such as task_struct, inode, or network buffers. Instead of requesting raw memory pages from the buddy allocator, the kernel carves these pages into uniform "slabs" to reduce fragmentation and overhead. When a kernel module creates an object and fails to free it, those slabs remain "active," leading to a gradual exhaustion of kernel memory.
Monitoring Slab Usage
To detect leaks, we look for slabs that show a high number of active objects over a long duration. The primary interface for this is /proc/slabinfo.
You can inspect the state of all caches using the slabtop utility, which provides a real-time, top-like view:
# View active objects, objects per slab, and cache sizes
slabtop -s c
In the output, focus on the OBJS ACTIVE column. If you suspect a memory leak in a specific subsystem, observe the OBJS ACTIVE count while performing tasks related to that module. If the count increases monotonically and never returns to a baseline level after the task is finished, you have likely identified a leak.
Tuning for Debugging
If a leak is suspected, you can enable slab debugging to track allocation origins. This is done by booting the kernel with the slub_debug=PU,cache_name parameter (e.g., slub_debug=PU,dentry). The P flag enables poisoning (filling memory with a pattern to detect corruption), and the U flag enables user tracking, allowing you to see exactly where the object was allocated via dmesg.
Be aware that enabling these debugging features adds significant overhead and memory pressure, so they should only be used in controlled test environments to isolate the problematic subsystem. Once you identify which cache is growing unchecked, you can trace it back to the corresponding kernel module that consumes that specific object type.
Key Takeaway: By monitoring OBJS ACTIVE in /proc/slabinfo or using slabtop, you can identify kernel subsystems that fail to release memory, allowing you to isolate leaks before they impact system stability.