Thanks for trying out the iouring backend.
On Wed, Apr 28, 2021 at 11:24:49AM -0400, Olivier Langlois
<oliv...@trillion01.com> wrote:
> I believe that in order to achieve the performance gain that io_uring
> can deliver, you would need to service I/O through io_uring as well to
> save on the associated system call cost instead of just using io_uring
> for polling.
iouring being quite a bit slower than epoll was my own experience. That
and it being too buggy for general use (and obviously no movement of the
maintainer to fix things) made me kind of give up on this as a libev
backend. It can only work in some case,s or when you embed it into another
event loop. And then you can just embed iouring into an epoll loop to get
the best of both worlds.
> but if adding a function specific to libev io_uring backend that would
> let the watcher code perform their i/o requests through io_uring was
> thinkable, that could be the performance holy grail for libev users by
> only making 1 system call to service the 64 i/o operations.
The obvious way to do this would be to expose request submission. There are
two problems to solve though: a) how to identify/distinguish those requests
from libev's own ones and b) libev can tear down and open a new iouring at
any time, and this is hard to synchronise with external users.
It might be possible to do some kind of iouring watcher.
However, in the need, you can also use your own iouring and embed it into
libev. This will also take care of extra system calls, and is rather clean
and works with e.g. epoll as well, and might even be faster (certainly
more correct, as iouring is too buggy as a generic event backend).
> In the meantime, I took care of one of the TODO item. That is using a
> single mmap() when possible. It is essentially code from liburing
> adapted to libev coding style...
Thanks, when I come around to implement this I will certainly take
advantage of your work, although this is currently on the back burner due
to the issues with iouring.
Would it be possible to re-send the patch properly though? The version you
sent is completely garbled because there are extra spurious newlines all
over the place.
> By switching from epoll backend to io_uring one, my process CPU usage
> did drop from 20-30% to below 5%. It seems too good to be true!
> What I suspect happening is that my socket option SO_BUSY_POLL setting
> might not be honored by io_uring.
That indeed sounds too good to be true. In my tests iouring is consistently
slower, although I can imagine that in workloads which are very heavy on
syscalls (e.g. epoll_ctl) this might change.
On the other hand, epoll now has a mode where it can also queue things
with few syscalls, and as much as I hate epoll, since iouring is going
down the same road as linux aio (buggy, never getting fixed), it is
probably the way to go for the future.
On Wed, Apr 28, 2021 at 11:31:47AM -0400, Olivier Langlois
<oliv...@trillion01.com> wrote:
> Here is a last quick sidenote concerning my CPU usage observation.
>
> CPU usage reported by top is now below 5% when using io_uring backend
> but it seems like the CPU is spent by something else inside the kernel
> as my average load did pass from 2.5 to ~3.1...
I would expect that all other things being similar, that things take more
cpu, as iouring seems to be vastly less efficient as epoll (e.g. its use of
hash tables instead of a simple array lookup for everything is bound to slow
things down).
It might be possible that this is improved in future versions of the
kernel, but I am doubtful that it can ever reach epoll speeds, especialy
if a queueing system is used for epoll as well (which libev does not yet
implement).
All of this points ot being the right solution to use iouring for the things
only it can do (I/O) and using epoll with a submission queue for the rest.
--
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
