Linus Torvalds merges /proc/filesystems speedup for Linux 7.2

Linux kernel maintainers merged a /proc/filesystems rework for Linux 7.2 that targets a small file with a large call count. The patch series caches the text that userspace reads from /proc/filesystems and converts the filesystem list to RCU, cutting repeated read overhead by up to 444% in the reported benchmark.

The file lists filesystem types that the running kernel can mount. You can inspect it with cat /proc/filesystems, and many programs touch it through library code rather than through a command you typed with that goal. Christian Brauner pointed to libselinux as the source of much of that traffic. The SELinux userspace library links into many command-line tools, including tools that users may not connect with filesystem discovery.

The old path made each read walk a hand-managed linked list and format each filesystem entry on demand. That design made sense when developers treated the file as an occasional inspection endpoint. It cost more once library calls turned it into a hot path.

Kernel developers changed two parts of the path. First, they moved the filesystem list to read-copy-update, or RCU, a kernel synchronization scheme built for read-heavy data. The kernel's RCU documentation describes the model: readers proceed without taking a traditional lock, while writers publish updates in a way that lets old readers finish against the prior version.

Second, they pre-generate and cache the string that /proc/filesystems returns. Instead of chasing pointers and formatting rows on each read, the kernel can hand userspace a prepared buffer until the filesystem list changes.

That second change explains the large benchmark gain. A tiny procfs file can cost too much when the kernel repeats list walking, string formatting and reference maintenance across a flood of short-lived opens. Caching turns that work into an update-time cost. Readers pay less, and systems with many processes avoid needless contention.

The change also marks the proc file as permanent through procfs support outside fs/proc/. That lets the kernel bypass reference work on open and close for this case. On a laptop, you may see no visible change from one shell command. On a busy SELinux-enabled server, container host or CI worker, the savings add up across process launches and policy checks.

The compatibility story looks clean. Userspace still reads the same interface documented in the kernel's procfs guide. Scripts that parse /proc/filesystems should see the same list shape, including nodev entries for pseudo filesystems. The patch changes how the kernel prepares the bytes, not the contract that user programs consume.

Performance data in the Phoronix report puts the best case at 444% faster than current kernel releases. That number needs the usual benchmark context: a microbenchmark that reads one proc file will show the cleanup with more force than a full application run. The gain still matters because the file sits under code paths that run many times per boot, login session and package script.

Area	Old path	Linux 7.2 path
Data structure	Hand-rolled linked list	RCU-protected filesystem list
Read behavior	Walk and format entries per read	Return cached generated string
Open and close cost	Maintain proc references	Bypass reference work for permanent proc file
Best reported gain	Baseline	Up to 444% faster

Power consumption follows the same logic, even if the report does not give wattage numbers. Less pointer chasing and less formatting mean fewer CPU cycles per read. You should not expect a measurable wall-plug drop from this patch alone on a desktop. On dense servers that launch many short processes under SELinux policy, shaving small kernel costs can reduce aggregate CPU time.

Build recommendations stay conservative. Homelab builders who run SELinux, container stacks or many automation jobs should treat Linux 7.2 as a useful kernel once distributions ship it, but this patch does not justify a custom kernel by itself. The change has its best value as part of a broader 7.2 update, especially on machines where process startup cost and syscall pressure show up in traces.

Developers can test their own systems with strace -f -e openat,read your-command and look for /proc/filesystems reads. For deeper measurement, use perf stat around a loop that launches the workload you care about, then compare kernels under the same CPU governor and SELinux mode. Synthetic loops that run cat /proc/filesystems can confirm the kernel-side speedup, but application-level tests tell you whether the optimization matters for your build server or storage node.

{{IMAGE:2}}

The broader lesson lands in procfs design. Files under /proc often look like debug scraps, but userspace libraries can turn them into production dependencies. Once a library reads one file during startup or policy setup, thousands of unrelated programs inherit that cost. Kernel maintainers found a cheap fix here: cache stable text, use a read-optimized list and remove open-close bookkeeping where procfs can prove the file stays around.

Linux 7.2 should ship this as a quiet storage and procfs cleanup rather than a headline feature. The patch will not change mount behavior or filesystem support. It will make a small kernel interface cheaper for the programs that ask the same question again and again.