Storage-intensive apps on tokio: when it's time to reach for io_uring
summary
Page server moves tokio IO onto io_uring by building tokio-epoll-uring, a library that submits io_uring SQEs from within a vanilla Tokio process and awaits completions via an async_fd-driven task. It guarantees nonblocking IO, requires no extra threads or runtime, and yields a proof-of-concept 10x better tail latency for batch submission, but stops short of a native runtime: ext4 blocking corner cases, lack of a batch-submit API, and an extra wake-up “trampoline” that delays completions remain practical limits.
AI-written summary · about
chapters (9)
- 0:00Storage workloads intro
- 1:18Neon’s page server
- 5:56Naive Tokio with spawn_blocking
- 9:52Async IO with io_uring
- 11:56How io_uring works
- 22:10Ext4 buffered reads
- 24:57Tokio-uring for page server
- 30:56Performance gains and limits
- 32:42Call to Tokio optimizations
related talks
29mI/O in Rust: the whole story
06mZero-copy Transfers with io_uring and Rust
32mTechniques for writing concurrent applications with asynchronous I/O
05m“Using async-profiler to Find Tail Latency Issues”
45mKeynote | Actors with Tokio – a lesson in ownership
30mWriting High Performance Async IO Apps
29mAsychronous programming in Rust
51mThousands of Async Tasks per Second in the Cloud on Rust/Axum/Tokio