Pins tagged “io_uring”

A paper on why io_uring workloads are so hard to see into, and what it takes to fix that. Because submission and completion happen in rings shared with the kernel, strace catches only the setup call, and the tracepoints that expose the actual request flow are not stable ABI, so the tools built on them work on narrow kernel ranges and break elsewhere. uringscope is a single binary eBPF tool that reconstructs per request lifecycles anyway, leaning on BTF probed program variants, field flavors, and position independent reads to survive struct layout drift across kernels. The evaluation is the part worth sitting with: aggregate mode costs 0.7 to 9.9% of throughput on device bound NVMe, cheaper than any full fidelity alternative measured, and the same reconstruction feeds a correctness mode that flags submission boundary hazards and reports named pathologies with the evidence behind them, aimed at someone in the middle of a latency incident rather than browsing histograms.

An engineering writeup from the ScyllaDB team on reworking Seastar's io_uring backend so application shards stop spending their own CPU cycles on I/O. Instead of every shard issuing syscalls, shards are grouped and each group hands its asynchronous I/O to a dedicated networking core; the chosen design gives each shard a private io_uring instance while sharing kernel worker pools through IORING_SETUP_ATTACH_WQ, with a single SQPOLL thread polling the group's submission queues so nothing blocks on the compute cores. The post is candid about the tradeoffs, walking through three architectures the team weighed and measuring where the asymmetric backend actually wins on compute heavy request handling versus where one networking core becomes the bottleneck on copy_to_user for pure I/O workloads.