3 ms·
The 8x speedup seems to come from a microbenchmark that requires no real async work from the kernel (so I think is mostly going to be stressing out context swit
by dan-robertson 3y ago
The 8x speedup seems to come from a microbenchmark that requires no real async work from the kernel (so I think is mostly going to be stressing out context switches and the threadpool data structures in the non-uring case) but I’m still excited about the improvements to async io from io_uring.
Question I’ve not figured out yet: how can one trace io_uring operations? The api seems kinda incompatible with ptrace (which is what strace uses) but maybe there is an appropriate place to attach an ebpf? Or maybe users of io_uring will have to add their own tracing?
- truth_seeker 3y agoObservability on how kernel handles io_uring request - https://github.com/axboe/liburing/issues/467 https://github.com/axboe/liburing/issues/467
- tptacek 3y agoYes: the title of this post should be "libuv: introduce io_uring support", not what it is now.
- znpy 3y ago> The 8x speedup seems to come from a microbenchmark that requires no real async work from the kernel which is nice because you can measure the actual library overhead without the noise from real kernel work.
- theLiminator 3y agoYeah, might have been better to reword it as a "8x reduction in overhead" or something to make it more clear that it's highly unlikely you'll see this in real workloads.