Kernel Memory: `slabtop`

Where Did My RAM Go?

Imagine you add up the memory usage of every process on your system using ps aux and the total comes to 4 GB. But free -m reports 10 GB used. The missing 6 GB is not a bug or a leak — it is the kernel itself consuming memory for its own bookkeeping, and it is invisible to process-level tools.

The Linux kernel needs to allocate memory constantly: every open file needs a structure to track it, every network connection needs a socket buffer, every directory lookup needs a cached result. Rather than calling the general memory allocator for each tiny object (which would be slow and cause fragmentation), the kernel uses the Slab Allocator.

The Slab Allocator works like a factory with pre-stamped parts. It pre-allocates pools of fixed-size objects for each type of kernel structure. When the kernel needs a new dentry (directory entry) object, it grabs one from the pre-allocated pool in microseconds rather than carving out new memory. When the object is freed, it goes back to the pool rather than being returned to the general heap.

The Tool: slabtop

slabtop reads from /proc/slabinfo and presents a real-time, sorted view of these kernel object caches. It requires root privileges to run.

The columns that matter:

Common culprits when RAM disappears:

• dentry: Directory Entry cache. Every file path lookup (open("/etc/passwd")) causes the kernel to cache the directory components. On a server with millions of small files (log directories, package caches, container image layers), this cache can consume several gigabytes. It is the single most common cause of "missing RAM" on busy filesystems.
• inode_cache: Metadata about files — permissions, ownership, timestamps. Grows alongside dentry.
• ext4_inode_cache: Filesystem-specific inode structures. Similar to above but for ext4 specifically.
• kmalloc-*: General-purpose kernel allocations of various sizes. A large kmalloc-4096 entry might indicate a driver or subsystem allocating many 4 KB objects.
• sock_inode_cache / TCP: Network socket structures. A server with thousands of simultaneous connections will show large values here.

Reclaiming slab memory:

The kernel will automatically reclaim slab caches under memory pressure — that is the normal, self-managing path. A manual override also exists, via a kernel-exposed control that can force-drop dentries, inodes, or the page cache on demand, but it is a blunt instrument: it does not fix anything, it just clears the cache and forces the kernel to re-warm it from storage. Do not run it on a production system without understanding the consequences — the cache exists because it is useful, and dropping it causes a temporary spike in disk I/O.