You probably think rmmod cleans up after itself perfectly, but in production, things get messy. I’ve spent enough nights tracking down why memory usage creeps up after dynamic module updates to know that the kernel doesn’t always reclaim everything. When you churn through drivers or custom modules, you’re occasionally leaving behind orphaned objects that don’t show up in standard free or top reports.

Why the reference count is lying to you

Even if your module reference count hits zero, the kernel might have pinned structures in the slab cache that simply won’t budge. This usually happens when you have active sysfs nodes or pending callbacks that didn’t unregister cleanly. You think you’ve cleared the stage, but the ghosts remain in kernel memory, and you’ll eventually trigger an OOM killer event that makes no sense given your workload.

lsmod | grep -E '^\S+\s+[0-9]+\s+0'

• Check /proc/modules to see if the status is marked as ‘Loading’ or ‘Live’ even when refcount is zero
• Inspect dmesg for tainting warnings that suggest a memory leak during initialization
• Monitor /proc/slabinfo for specific caches that fail to shrink after an rmmod command

If you see your slab usage growing despite an empty module list, force a cache reclaim by writing to the drop_caches file. It is a blunt instrument, sure, but it will tell you immediately if the kernel is actually holding onto those pages or if you have a true leak in your module code that needs a proper fix. Don’t just ignore a creeping memory graph; eventually, the kernel will stop asking politely and start killing processes.