4 ms·

Only if they are highly I/O bound. For example, implementing tcp/http/udp proxy servers. Static file servers too can benefit greatly.

• Misdicorl 3y ago
  Nit: Syscall bound, not necessarily I/O bound.
  • dontlaugh 3y ago
    Both, because it allows async file I/O.
    • Misdicorl 3y ago
      Your application must feel I/O bound. But in reality it must be syscall bound in order for io_uring to make any noticeable improvement. In other words: if your application is already writing/reading at the max speed the hardware its on allows, you will see no improvement from this. That application is truly I/O bound. An application that feels I/O bound will be doing lots and lots of little reads and writes and achieving low hardware utilization. That application is syscall bound rather than I/O bound, and io_uring will help tremendously.
• bhaney 3y ago
  Based on an exchange in the PR, it sounds like they have to be specifically bound on file I/O to see an improvement, not network I/O. > is this PR just for files or also for network operations? > Just file operations for now.
  • truth_seeker 3y ago
    Ouch ! I missed that comment. Not sure, why they ignored socket, it would be have been great addition to NodeJS/Python stack. Let's hope they make it happen in near future release schedule.
    • junon 3y ago
      io_uring was made primarily for filesystem operations and is most optimized for that use case. Other file descriptor types have to be explicitly handled by the kernel side of the io_uring implementation, and while network calls are among those that have been, they still all require different handling in some cases.