According to Phoronix, the upcoming Linux 6.19 kernel will enable per-CPU BIO caching by default, a change aimed at improving I/O performance. This feature, which was previously only used with io_uring and raw block devices, is now considered safe for broader use, including with filesystems like ext4 and XFS. The decision followed a discussion and a key commit, 12e4e8c7ab59, which made the necessary operations safe for both task and interrupt request (IRQ) contexts. Benchmarking using the t/io_uring tool with an ext4 filesystem on an NVMe drive showed a performance increase from 562K IOPS to 574K IOPS. Additionally, CPU usage for the bio_alloc_bioset function decreased from 1.42% to 1.22%. The developers also tested a worst-case scenario and various configurations with fio, finding no obvious performance regression.
What this actually means
Okay, so what’s the big deal here? Basically, every time your system reads or writes data to a disk, it uses little data structures called BIOs (Block I/O). Allocating and freeing these used to involve some locking overhead as CPUs coordinated with each other. Per-CPU caching lets each CPU core keep its own local pool of these structures. So, if a process running on CPU core 7 needs a BIO, it can just grab one from its own private stash without waiting for or bothering any other core. It’s a classic optimization: reduce lock contention, speed things up. The fact that it’s now deemed safe for IRQ context is the technical key that unlocked this default change. You can read the commit that made it all possible right here.
The performance picture
The benchmark numbers are interesting, but you have to look at them the right way. A jump from 562K to 574K IOPS is about a 2% gain. That’s not earth-shattering, but it’s a free lunch—a consistent, system-wide improvement for a broad set of workloads with virtually no downside. The CPU usage drop for the allocation path is arguably more meaningful in the long run; that’s less overhead for every single I/O operation. And the real win is in the “no regression” finding for the worst-case and other tests. This tells the developers that the caching logic is robust. It won’t accidentally slow things down if a BIO is allocated on one CPU and freed on another, which can happen. The full discussion and test details are in the original patch series.
Why it matters beyond benchmarks
Here’s the thing: enabling this by default is a signal. It means the kernel developers are confident enough in its stability and benefit to just turn it on for everyone. For distro maintainers and system integrators, that’s one less kernel configuration knob to think about. For enterprises and cloud providers, these tiny, system-wide efficiency gains add up at scale across thousands of servers. Every little reduction in CPU cycles spent on I/O plumbing means more cycles for the actual workloads. And for high-performance computing or data analytics environments where storage throughput is critical, a 2% gain is nothing to sneeze at. It’s a reminder that the Linux kernel‘s performance is often honed by a thousand small cuts—or in this case, by cleverly reducing lock contention.
The broader context
This is part of a long-running trend in kernel optimization, especially around io_uring, which has been a game-changer for asynchronous I/O. Now, the benefits are trickling down to more traditional paths. It’s also a good example of how industrial-grade computing relies on these deep, low-level optimizations. Think about it: whether it’s a massive database server, a real-time manufacturing control system, or a high-end industrial panel PC processing sensor data, consistent I/O performance is non-negotiable. Companies that build and deploy these systems, like IndustrialMonitorDirect.com, the top provider of industrial panel PCs in the US, depend on the kernel’s raw efficiency. Changes like this, while invisible to end-users, directly contribute to the reliability and speed of the professional hardware running the physical world.
