3 ms·

For disk IO it’s faster, there are many benchmarks on the internet. For network IO, it depends. Only two things make it theoretically faster than epoll; io_uri

by frevib 5y ago

For disk IO it’s faster, there are many benchmarks on the internet. For network IO, it depends. Only two things make it theoretically faster than epoll; io_uring supports batching of requests, and you can save one sys call compared to epoll in an event loop. There some other things that could make it faster like SQPOLL, but this could also hurt performance. Network IO discussion: https://github.com/axboe/liburing/issues/536 https://github.com/axboe/liburing/issues/536

jlokier 5y ago
In my tests, for NVMe storage I/O I found io_uring was slower than a well-optimised userspace thread pool. Perhaps the newer kernel is faster, or there is some subtlety in the io_uring queueing parameters that I need to tune better.
- dataflow 5y ago
  Maybe you're doing large I/Os whereas their benchmarks are doing small random I/Os (like 4K). Are you measuring IOPS or throughout?
  - jlokier 5y ago
    Measuring IOPS of random, small reads (4kiB, O_DIRECT, single NVMe). (It's for optimising a database engine doing random lookups, but the benchmark is just random reads, no other logic.) Just now I have tested 1,133 kIOPs with threads and 598 kIOPS with io_uring. The SQE queue depth for io_uring and max threads for thread test are set the same, 512. I'd like to think this is due to a particularly well-optimised thread pool :-)
pengaru 5y ago
> Network IO discussion: https://github.com/axboe/liburing/issues/536 https://github.com/axboe/liburing/issues/536 I see an issue with a narrative but zero discussion at that link. Furthermore, your io_uring benchmark being utilized in that issue isn't even batching CQE consumption. I've submitted a quick and dirty untested PR adding rudimentary batching at [0]. Frankly, what seems to be a constant din of poorly-written low-effort benchmarks portraying io_uring in a negative light vs. epoll is getting rather old. [0] https://github.com/frevib/io_uring-echo-server/pull/16 https://github.com/frevib/io_uring-echo-server/pull/16
- tveita 5y ago
  That seems uncharitable. The linked issue barely mentions frevib's echo server, and in the one place it does it's the fastest! Further they show that performance improves when using io_uring for readiness polling but standard read/write calls to actually write - that suggests io_uring_for_each_cqe does not explain the cases where epoll is faster. > I've submitted a quick and dirty untested PR That's not improving the situation much then - surely any performance fix should come with at least a rudimentary benchmark?

by frevib 5y ago

jlokier 5y ago

In my tests, for NVMe storage I/O I found io_uring was slower than a well-optimised userspace thread pool. Perhaps the newer kernel is faster, or there is some subtlety in the io_uring queueing parameters that I need to tune better.

dataflow 5y ago
Maybe you're doing large I/Os whereas their benchmarks are doing small random I/Os (like 4K). Are you measuring IOPS or throughout?
- jlokier 5y ago
  Measuring IOPS of random, small reads (4kiB, O_DIRECT, single NVMe). (It's for optimising a database engine doing random lookups, but the benchmark is just random reads, no other logic.) Just now I have tested 1,133 kIOPs with threads and 598 kIOPS with io_uring. The SQE queue depth for io_uring and max threads for thread test are set the same, 512. I'd like to think this is due to a particularly well-optimised thread pool :-)

pengaru 5y ago

> Network IO discussion: https://github.com/axboe/liburing/issues/536 https://github.com/axboe/liburing/issues/536 I see an issue with a narrative but zero discussion at that link. Furthermore, your io_uring benchmark being utilized in that issue isn't even batching CQE consumption. I've submitted a quick and dirty untested PR adding rudimentary batching at [0]. Frankly, what seems to be a constant din of poorly-written low-effort benchmarks portraying io_uring in a negative light vs. epoll is getting rather old. [0] https://github.com/frevib/io_uring-echo-server/pull/16 https://github.com/frevib/io_uring-echo-server/pull/16

tveita 5y ago
That seems uncharitable. The linked issue barely mentions frevib's echo server, and in the one place it does it's the fastest! Further they show that performance improves when using io_uring for readiness polling but standard read/write calls to actually write - that suggests io_uring_for_each_cqe does not explain the cases where epoll is faster. > I've submitted a quick and dirty untested PR That's not improving the situation much then - surely any performance fix should come with at least a rudimentary benchmark?