4 ms·
I used to do asynchronous io with epoll, aio etc and spend time benchmarking my servers vs completion ports and kqueue etc. eventually libraries like Libuv tur
by willvarfar 7y ago
I used to do asynchronous io with epoll, aio etc and spend time benchmarking my servers vs completion ports and kqueue etc.
eventually libraries like Libuv turned up and made my life a lot easier.
Are there any good stats on how io_uring compares to all those older async io stuff?
- thedance 7y agoCheck the PDF that the article references, which also links to https://lore.kernel.org/linux-block/20190116175003.17880-1-axboe@kernel.dk/ https://lore.kernel.org/linux-block/20190116175003.17880-1-a...
- khc 7y agoepoll doesn't allow you to do async io to local storage, and io_uring doesn't target the network use case, so they are not quite comparable.
- jabl 7y agoThough it was originally designed for block io, IIRC io_uring has since added support for network sockets. Don't know how it compares to epoll performance-wise.
- wbl 7y agoYou have to allocate buffer per socket with io_uring, rather then reuse for each one that is ready. Most applications do this anyway though.
- GrayShade 7y agoThis is addressed in the article comments: https://lwn.net/Articles/810558/ https://lwn.net/Articles/810558/.
- yxhuvud 7y agoEh, nothing stops you from using a single buffer, but with different offsets for each open call. So I don't really see the problem unless you have so much buffer space allocated that it becomes problematic.
- cesarb 7y agoA "single buffer, but with different offsets for each open call" is identical to "allocate one buffer per socket" (you "allocated" the per-socket buffer by subdividing a larger allocation). And even if you don't "have so much buffer space allocated that it becomes problematic", it's still a waste of memory.
- gpderetta 7y agoI think the usual trick of using 0 sized buffers for readiness and just do the read synchronously might work. In fact io_uring might have direct support for polling now.
- topspin 7y ago> io_uring doesn't target the network use case There are several io_uring opcodes intended specifically for the network use case, including: IORING_OP_ACCEPT, IORING_OP_CONNECT, IORING_OP_SENDMSG and IORING_OP_RECVMSG. Did you mean something else by 'target'?
- khc 7y agoiirc it wasn't created for network IO, but I could be wrong
- yxhuvud 7y agoThe reason it was created and what it targets are different things. io_uring is evolving to be a very general way to do async interaction with the kernel, and the way it is built enables high performance also for things that isn't disk IO.
- frevib 7y agoHere are echo servers with io_uring: https://github.com/frevib/io_uring-echo-server https://github.com/frevib/io_uring-echo-server epoll: https://github.com/frevib/epoll-echo-server https://github.com/frevib/epoll-echo-server kqueue: https://github.com/frevib/kqueue-echo-server https://github.com/frevib/kqueue-echo-server io_uring performs much better than epoll: https://twitter.com/hielkedv/status/1218891982636027905?s=21 https://twitter.com/hielkedv/status/1218891982636027905?s=21
- deleted 7y ago[deleted]
- GrayShade 7y agoNot bad, according to one test: https://github.com/libuv/libuv/issues/1947#issuecomment-485230126 https://github.com/libuv/libuv/issues/1947#issuecomment-4852.... Note that it might have been optimized more in the meantime.
- Matthias247 7y agoThat is for file IO, for which there were not many working async options available. I think the parent was rather interested in how it compares for IO loads where epoll & co are already alternatives.