5 ms·
What's funny about io_uring is that the blocking syscall interface was always something critics of Unix pointed out as being a major shortcoming. We had OSes th
by api 5y ago
What's funny about io_uring is that the blocking syscall interface was always something critics of Unix pointed out as being a major shortcoming. We had OSes that did this kind of thing way back in the 1980s and 1990s, but Unix with its simplicity and generalism and free implementations took over.
Now Unix is finally, in 2021, getting a syscall queue construct where I can interact with the kernel asynchronously.
- CodesInChaos 5y agoio_uring is Linux specific. BSD offers kqueue instead, introduced in 2000. I believe both are limited to specific operations, mostly IO, and aren't fully general asynchronous syscall interfaces.
- rapsey 5y agoThe entire point of the article is that it is not just for IO.
- binarycrusader 5y agoThe OP said mostly IO not only.
- CodesInChaos 5y ago> The entire point of the article is that it is not just for IO I went through the list of operations supported by `io_uring_enter`. Almost all of them are for IO, the remainder (NOP, timeout, madvise) are useful for supporting IO, though madvise might have some non-IO uses as well. While io_uring could form the basis of a generic async syscall interface in the future, in its current state it most certainly is not. The article mostly talks about io_uring enabling completion based IO instead of readiness based IO. AFAIK kqueue also supports completion based IO using aio_read/aio_write together with sigevent.
- deleted 5y ago[deleted]
- coder543 5y ago> AFAIK kqueue also supports completion based IO using aio_read/aio_write together with sigevent. If you can point to a practical example of a program doing it this way and seeing a performance benefit, I would be curious to see it. I did some googling and didn't really even find any articles mentioning this as possibility. kqueue is widely considered to be readiness based, just like epoll, not completion based. What you wrote sounds like an interesting hack, but I'm not sure it counts for much if it is impractical to use.
- CodesInChaos 5y agoI don't know if it offers any practical benefits for sequential/socket IO. But AFAIK it's the way to go if you want to do async random-access/file IO.
- funny_falcon 5y agoAfaik, Nginx used this hack for aio on FreeBSD many years. It is superrior to aio on Linux. That is why Netflix used nginx together with FreeBSD. Now nginx could use threads for file io, and linux file performance became ok as well.
- mzs 5y agoIt feels like it's been ten years since I fiddled with this on FreeBSD but EVFILT_AIO worked surprisingly well with aio and kqueue on spinning disk.
- asveikau 5y agoPOSIX AIO uses `struct sigevent` to notify completion. On FreeBSD you can set ->sigev_notify to SIGEV_KEVENT, and ->sigev_notify_kqueue to a kqueue descriptor. As for your "performance benefit" question and nobody using it over readiness based approaches: Well yes. No idea how it compares with a traditional readiness based socket program. But it's kind of not the point either. AFAIK the scenario where POSIX AIO makes most sense is files on disk.
- lonjil 5y agoThere's nothing stopping io_uring from gaining more non-IO operations, and indeed that appears to be the plan.
- asveikau 5y agokqueue is not really a replacement for io_uring. That said, FreeBSD can make a POSIX AIO request signal completion to a kqueue, which is a similar model of async I/O. But as has been pointed out elsewhere, io_uring is also about making other syscalls asynchronous.
- binarycrusader 5y agoSolaris had this over a decade ago now with event ports which are basically a variant of Windows IOCP: https://web.archive.org/web/20110719052845/http://developers.sun.com/solaris/articles/event_completion.html https://web.archive.org/web/20110719052845/http://developers... So at least one UNIX system had them a while ago.
- wahern 5y agoPeople keep saying this but IME that's not how the Solaris Event Ports API works at all. The semantics of Solaris Event Ports is nearly identical to both epoll+family and kqueue. And like with both those others (ignoring io_uring), I/O completion is done using the POSIX AIO interface, which signals completion through the Event Port descriptor. I've written at least two wrapper libraries for I/O readiness, POSIX signal, file event, and user-triggered event polling that encompass epoll, kqueue, and Solaris Event Ports. Supporting all three is relatively trivial from an API perspective because they work so similarly. In fact, notably all three let you poll on the epoll, kqueue, or Event Port descriptor itself. So you can have event queue trees, which is very handy when writing composable libraries.
- deleted 5y ago[deleted]
- PaulDavisThe1st 5y agoMaybe Linux will get scheduler activations in the near future, another OS feature from the 90s that ended up in Solaris and more or less nowhere else. "Let my user space thread scheduler do its work!"
- aseipp 5y agoThere's already plans for a new futex-based swap_to primitive, for improving userland thread scheduling capabilities. There was some work done on it last year, but it was rejected on LKML. At this rate, it looks like it will not move forward until the new futex2 syscall is in place, since the original API is showing its age. So, it will probably happen Soon™, but you're probably still ~2 years out before you can reliably depend on it, I'd say.
- PaulDavisThe1st 5y agoScheduler activations don't require swap_to. The kernel wakes up the user space scheduler when it decides to put the process onto a cpu. The user space scheduler decides which user space thread executes in the kernel thread context that it runs in, and does a user space thread switch (not a full context switch) to it. It's a combination of kernel threads and user space (aka "green") threads.
- rektide 5y agoIt might! I'm not sure if it's an exact fit or not but the User Managed Concurrency Groups work[1] Google is trying to upstream with their Fibers userland-scheduling library sounds like it could be a match, and perhaps it could get the upstreaming itcs seeking. [1] https://www.phoronix.com/scan.php?page=news_item&px=Google-Fibers-Toward-Open https://www.phoronix.com/scan.php?page=news_item&px=Google-F...
- deleted 5y ago[deleted]
- gpderetta 5y agoI think some of the *BSDs have (or had) it. Linux almost got it at the turn of the millennium, with the Next Generation Posix Threading project, but then the much simpler and faster NPTL won.
- ww520 5y agoI remember IPX has similar communication model. To read from the network, you post an array of buffer pointers to the IPX driver and can continue to do whatever. When the buffers are filled, the driver calls your completion function.
- mpweiher 5y agoDo you have some references?