RFC shards procfs inode lists to cut lock storms on big boxes

Huang Shijie has floated an RFC on the Linux kernel list to break up the single global inode list used by procfs, targeting lock contention that can dominate large multiprocessor machines.

On a 384-CPU, 12-NUMA-node Hygon box running Hadoop TestDFSIO (a thousand concurrent 100MB reads), the superblock inode-list lock consumed roughly 90% of a hot path inside procfs. About half the pressure came from creating inodes while walking process file-descriptor directories; most of the rest came from tearing them down on task exit. After the proposed changes the same lock hotspot fell to about 1% and the workload finished more than 50% faster.

The series first stops the drop-caches path from walking procfs at all, because that filesystem has no page cache. It then adds a small helper that asks whether a superblock’s inode list is empty, and finally replaces the single procfs list with a set of shards. The number of shards is scaled to the CPU count; each carries its own spinlock and is cache-line aligned to limit false sharing across NUMA nodes. Inodes are placed round-robin, and optional super-operations callbacks let a filesystem own its list management. Eviction and unmount walk every shard when the list is marked sharded.

Syzbot’s continuous integration immediately reported a KASAN slab-out-of-bounds read while tearing down a superblock under the new code. Separately, Alexey Dobriyan argued that skipping procfs in drop-caches should not hard-code a magic number: other synthetic filesystems also lack page cache, so a superblock flag would be cleaner. Shijie agreed, tried a backing-device check that collided with tmpfs, and is now considering an explicit flag.

The work remains an RFC; both the crash and the drop-caches design need resolution before anything can merge.