Pins tagged “io_uring”

A paper on why io_uring workloads are so hard to see into. Submission and completion happen in rings shared with the kernel, so strace catches only the setup call and you are left guessing when something goes wrong. uringscope is a single binary eBPF tool that watches those rings and rebuilds the life of each request from raw kernel events, using CO-RE, BTF probes, and flexible field lookups so one build survives the tracepoint churn across kernel versions. On real NVMe workloads it costs about 0.7 to 9.9 percent of throughput, cheaper than the other tools measured at the same level of detail. The same data feeds a doctor mode that turns raw measurements into named problems with the evidence behind them, aimed at someone chasing a tail latency bug rather than browsing histograms.

A ScyllaDB engineering post about a new io_uring backend for Seastar that breaks the usual shared nothing rule, where every core does its own I/O and compute. The asymmetric backend instead sets aside a few cores as dedicated networking workers while the rest run only application logic, and routes I/O syscalls to those workers through io_uring queues. To make it work the team had to remove a speculative fast path that let a shard skip io_uring and issue a plain syscall on its own core, since that shortcut defeats the point of offloading. The numbers are honest about the tradeoff: raw I/O throughput trails the older linux aio backend, but compute shards get back the CPU time they used to spend on sockets and disk calls.