On Sun, Mar 22, 2020 at 05:57:02PM -0400, Benjamin Mahler
<benjamin.mah...@gmail.com> wrote:
> Thanks Marc, do you have any broader comments on the implications of
> iouring for libev? It looks like iouring is finally bringing async system
> calls (not just async io) to Linux.
As far as I have been told, you will even be able to upload (ebpf)
programs into the kernel, and you can already do chained requests of
sorts (open/read/close for example).
I haven't seen direct signs of bringing async system calls into iouring
though, but that might be because I am simply uninformed, and concentrate
on what libev needs first. It's also not really a concern for either
libeio or libev.
> Will libeio have an iouring backend that doesn't use a thread pool and
> instead hands the io off to the kernel with io_uring?
I don't think the threadpool can be avoided, as some things will have to
be done in userspace (e.g. eio_readdir), but yes, as a very heavy libeio
user I'd be very keen on getting many requests into iouring, stat(x),
open/close, read/write are pretty high in my personal priority list, and it's
certainly possible to do this in smaller steps.
This will be useful even if io_uring turns out to be slower than epoll
for I/O notifications - which is an ongoing concern, due to the less
streamlined API (e.g. io_uring requires a hash lookup to find watchers
whereas epoll can just use an array lookup, and this is worsened by
io_uring requiring kernel interactions per event notification and not just
per watcher, as epoll does). But even if slightly slower, it might still
become the default backend simply because it avoids so many design issues
that epoll suffers from.
I currently can't see a reasonably easy way of sharing the io_uring
between libev and libeio, so they will likely use a separate io_uring
instance anyway.
But while I am confident on the plans for libeio, I am less confident
on the timeframe - it might be very quick, or it might take a long
time. Important will be my experiences with io_uring in libev w.r.t.
speed and queuing behaviour - libev already had some major design changes
internally to accomodate io_uring (as documented in fd_reify), which can
bring some instability to the codebase.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
