libev-4.31 has just been released

[Olivier Langlois]

Hi,

I just wanted to report back that my usage with libev iouring backend
appears to be working super fine.

It is a WebSocket client opening about 64 TCP connections.
The test has been performed with kernel 5.11.14.

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.

Ultimately, what I am looking to improve is my application reaction
time. I might have more to say about io_uring effect on latency in 24h-
48h from now when I had the chance to collect some data.

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.

ie: currently, if data is available for reading for my 64 sockets and I
call read() 64 times from my libev io watcher callback. There is not
much performance gain here by using io_uring.

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.

drawback of this optimization is that the watcher code couldn't be use
anymore with the other backends but that is the cost to pay to be able
to use a new API to its full potential...

I will probably end-up modifying my local copy of libev to play with
the idea. Let me know if there would be interest in knowing how my
experiment goes.

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...

$ diff ev_iouring.c.orig ev_iouring.c
64c64
<  *    occur to him, and he made good on it by adding an unlimited
nuber
---
>  *    occur to him, and he made good on it by adding an unlimited
number
82c82
< /* TODO: take advantage of single mmap, NODROP etc. */
---
> /* TODO: take advantage of NODROP etc. */
323c323,324
<   if (iouring_cq_ring != MAP_FAILED) munmap (iouring_cq_ring,
iouring_cq_ring_size);
---
>   if (iouring_cq_ring != MAP_FAILED && iouring_cq_ring !=
iouring_sq_ring)
>     munmap (iouring_cq_ring, iouring_cq_ring_size);
346c347
<   if (!have_monotonic) /* cannot really happen, but what if11 */
---
>   if (!have_monotonic) /* cannot really happen, but what if!! */
360c361
<       if ((~params.features) & (IORING_FEAT_NODROP |
IORING_FEATURE_SINGLE_MMAP | IORING_FEAT_SUBMIT_STABLE))
---
>       if ((~params.features) & (IORING_FEAT_NODROP |
IORING_FEAT_SUBMIT_STABLE))
380a382,388
>   if (params.features & IORING_FEAT_SINGLE_MMAP)
>     {
>       if (iouring_cq_ring_size > iouring_sq_ring_size)
>         iouring_sq_ring_size = iouring_cq_ring_size;
>       iouring_cq_ring_size = iouring_sq_ring_size; 
>     }
> 
383,384c391,395
<   iouring_cq_ring = mmap (0, iouring_cq_ring_size, PROT_READ |
PROT_WRITE,
<                           MAP_SHARED | MAP_POPULATE, iouring_fd,
IORING_OFF_CQ_RING);
---
>   if (params.features & IORING_FEAT_SINGLE_MMAP)
>     iouring_cq_ring = iouring_sq_ring;
>   else
>     iouring_cq_ring = mmap (0, iouring_cq_ring_size, PROT_READ |
PROT_WRITE,
>                             MAP_SHARED | MAP_POPULATE, iouring_fd,
IORING_OFF_CQ_RING);
637c648
<   /* we also clar the timeout if there are outstanding fdchanges */
---
>   /* we also clear the timeout if there are outstanding fdchanges */


On Thu, 2020-03-19 at 09:34 +0100, Marc Lehmann wrote:
> > Currently, the io_uring interface evelopment in libev is on hold,
> > awaiting
> 
> I might add, the iouring backend can be enabled in libev-4.33, and is
> expected to work. It has not really received testing, and it doesn't
> seem to
> have speed benefits yet.
> 
> Anybody is invited to experiment with it - just don't use it in
> production.
>