Is your feature request related to a problem? Please describe.
Quickwit's file I/O goes through Tokio's blocking thread pool because epoll does not support file descriptors. Under high query concurrency, each posting list fetch is a blocking read() dispatched to a thread, adding scheduling overhead and capping throughput. At sustained high QPS this becomes the dominant bottleneck.
Describe the solution you'd like
Use io_uring for file I/O in the search hot path. io_uring eliminates the syscall round-trip via a shared ring buffer between userspace and the kernel. For random-read workloads on NVMe (posting lists, doc store segments) benchmarks consistently show 40-60% latency reduction and 2x+ throughput at high concurrency.
Two implementation paths:
- compio -- async runtime built on
io_uring, composable with existing futures. Requires replacing Tokio file I/O in the search path.
- tokio-uring -- narrower scope, drop-in for Tokio's file ops.
Minimum kernel requirement: Linux 5.19. Can fall back to standard I/O on older kernels or non-Linux platforms.
Describe alternatives you've considered
Increasing the Tokio blocking thread pool size reduces contention but does not eliminate the syscall overhead or the context-switch cost per I/O operation.
Additional context
Apache Iggy (https://github.com/apache/iggy) runs its entire I/O stack on io_uring via compio (thread-per-core, shared-nothing). Their production experience serves as a reference implementation for this approach in a Rust async codebase.
Is your feature request related to a problem? Please describe.
Quickwit's file I/O goes through Tokio's blocking thread pool because epoll does not support file descriptors. Under high query concurrency, each posting list fetch is a blocking
read()dispatched to a thread, adding scheduling overhead and capping throughput. At sustained high QPS this becomes the dominant bottleneck.Describe the solution you'd like
Use
io_uringfor file I/O in the search hot path.io_uringeliminates the syscall round-trip via a shared ring buffer between userspace and the kernel. For random-read workloads on NVMe (posting lists, doc store segments) benchmarks consistently show 40-60% latency reduction and 2x+ throughput at high concurrency.Two implementation paths:
io_uring, composable with existing futures. Requires replacing Tokio file I/O in the search path.Minimum kernel requirement: Linux 5.19. Can fall back to standard I/O on older kernels or non-Linux platforms.
Describe alternatives you've considered
Increasing the Tokio blocking thread pool size reduces contention but does not eliminate the syscall overhead or the context-switch cost per I/O operation.
Additional context
Apache Iggy (https://github.com/apache/iggy) runs its entire I/O stack on
io_uringvia compio (thread-per-core, shared-nothing). Their production experience serves as a reference implementation for this approach in a Rust async codebase.