On 2/1/19 3:52 PM, Bart Van Assche wrote: > On Fri, 2019-02-01 at 08:23 -0700, Jens Axboe wrote: >> Here's v11 of the io_uring project. Main fixes in this release is a >> rework of how we grab the ctx->uring_lock, never using trylock for it in >> a user visible way. Outside of that, fixes around locking for the polled >> list when we hit -EAGAIN conditions on IO submit. This fixes list >> corruption issues with polling that some users have reported. >> >> As far as I'm concerned, this project is ready to get staged for 5.1. >> Please do review carefully so we can fix any minor nits that might still >> exist. >> >> The liburing git repo has a full set of man pages for this, though they >> could probably still use a bit of polish. I'd also like to see a >> io_uring(7) man page to describe the overall design of the project, >> expect that in the not-so-distant future. You can clone that here: >> >> git://git.kernel.dk/liburing >> >> Patches are against 5.0-rc4, and can also be found in my io_uring branch >> here: >> >> git://git.kernel.dk/linux-block io_uring >> >> Changes since v10: >> - Rework uring_lock locking >> - Ensure that async contexts lock when fiddling with polled lists >> - Minor tweak to io_iopoll_check() continue looping condition >> - Fold __io_uring_enter() into io_uring_enter() > > Hi Jens, > > Which goal(s) do you want to realize with this new API? Is the goal > perhaps to reduce the overhead of submitting I/O and receiving I/O > completions? If so, where can I find a comparison of the performance > of this API with libaio and synchronous I/O? Yes, it's to reduce the overhead of the interface, since aio isn't very good. It's also to provide something that's more feature rich. It's embarassing that we STILL don't have async buffered IO support, for instance. With this infrastructure, we do. In terms of benchmarks against aio, I included some in the v5 posting: https://lore.kernel.org/linux-block/20190116175003.17880-1-axboe@xxxxxxxxx/ I haven't done any against sync IO, but since you can use this interface in a sync manner (just have min_complete == to_submit), there won't be much of a difference, if any. If you use some of the more advanced features, like pre-mapped buffers, it'll be faster than the current sync IO. -- Jens Axboe
