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.
We had a similar experience in Polars trying to use io_uring.
Rust isn't inherently bad at io_uring but at least Tokio currently is. I'm not the one who implemented and benchmarked it so this is second-hand information but if I recall correctly Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.
Migrating our I/O to a different async runtime than Tokio was rejected. So we'll wait until it's fixed in Tokio and now use regular blocking reads instead.
Rust is just the language they happened to be working in. If you read through the LLM generated garbage it becomes clear that io_uring isnt the problem, their code was just slop / bad.
It would have been more precise to say O_DIRECT instead of io_uring. The point of io_uring is to avoid syscall overhead. What they were after was actually managing a page cache on their own, and it turned out to be more complicated than they thought.
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.
By the way, what does Rust have to do with their problem? Is Rust simply bad at io_uring? :)
Rust isn't inherently bad at io_uring but at least Tokio currently is. I'm not the one who implemented and benchmarked it so this is second-hand information but if I recall correctly Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.
Migrating our I/O to a different async runtime than Tokio was rejected. So we'll wait until it's fixed in Tokio and now use regular blocking reads instead.
But my interpretation is still more fun!
* 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.