Conviva swapped mmap for io_uring in its Rust query engine and got 60% slower
We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower

Conviva's Rust query engine, built on DataFusion and Arrow, replaced mmap with io_uring to escape page-cache thrashing under concurrent load. On Linux, total query time jumped from 13.6s to 21.8s, even though major page faults fell 35x. Minor faults rose 8x, and the team explains why bypassing the page cache isn't enough without better scheduling and concurrency.
Under load, page-cache thrashing and kernel-level lock contention — not disk I/O — were the bottleneck.
- jandrewrogers
An issue here is that mmap and io_uring require fundamentally different software architectures in a performance context. You shouldn’t swap them out.
APIs like io_uring, combined with O_DIRECT, allow you to design your own workload-specific userspace scheduler from first principles. If you are delegating scheduling to a runtime then you’ve forfeited most of the performance advantages those APIs were designed to provide. In many cases, the performance will be worse. By contrast, mmap implicitly delegates all scheduling decisions and it has some advantages if delegation is your strategy compared to a runtime.
The benefits of io_uring are limited without a commitment to designing your own schedulers. On the upside, skilled scheduler designers can increase performance by substantial integer factors using these APIs versus mmap. Designing application-specific schedulers is not easy, it is a high-skill endeavor. But the reward is real.
Using io_uring well requires going all-in on the software architecture it requires to show what it can do.
- laserbeam
The real issue here is there's a part 2 (linked at the end of the article) where they get the io_uring implementation to be twice as fast as mmap. So it's a clickbait title for a part 1, which gets resolved in part 2.
So they crunched out 2 articles, one of which is just ragebait. And they both seem LLM written. Maybe they have some cool advice, maybe not... but it's not a format I enjoy reading.
- londons_explore
There is a pattern in software engineering of:
* Project exists
* New employees come up with idea for efficiency improvement
* Months spent implementing. Old codepath becomes legacy.
* New thing now has extra features bolted on during build.
* Efficiency of new thing turns out worse than original, but now the new features and 'less technical debt' are the drivers.
* New thing launches, old thing deprecated, but there is little real benefit to all those months of work.