I get the feeling I'm going insane, or tmpfs is very broken for long term use.
I have a workload that very rapidly creates and unlinks files in /dev/shm/[some directory tree]. Linux Slab usage (in size-64 and size-128) increases linearly with inodes allocated/unlinked and never drops (the memory is listed an unreclaimable via meminfo, and slabinfo shows many millions of active objects).
This memory is never reclaimed, and if allowed to continue, OOM. The only fix is unmounting and remounting /dev/shm.
Another user asked this question a few years ago, but the answer did not actually cover the problem in question (operation in /dev/shm causes overflow).
Is this simply a design decision for tmpfs or is there something else going on here? It feels terribly broken that inodes would never be freed once allocated.
Timeline: Process creates 5 million files, one at a time, and unlinks each immediately after creation. All user processes killed at this point. Memory usage is as if 5 million inodes are still in /dev/shm, although df -i and df -h report that /dev/shm is essentially empty. Further iterations of the process loop linearly increase memory usage until the system is totally out of memory and OOMs.
EDIT: For anyone stumbling on this later, this seems to be an artifact of the older kernel I was running (SLES 11, 2.6.32-something). Newer kernels cannot reproduce the problem.