Announcement

Collapse
No announcement yet.

IO_uring To Ring In Some Awesome Improvements With Linux 6.0

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bug77 View Post

    I don't think this will translate in much performance gain for home PCs. I think this is more about doing things the right way (no extra copying, no unnecessary blocking.
    On that matter: how do you currently profit from io_uring without *directly* using low level C apis? Does boost/asio, for example, already support io_uring?

    Comment


    • #12
      Originally posted by oleid View Post

      On that matter: how do you currently profit from io_uring without *directly* using low level C apis? Does boost/asio, for example, already support io_uring?
      This is well out of my area of expertise, but if I understood correctly, you don't. At least not directly. This more happening within the kernel, while you keep calling the same kernel APIs you are used to.

      Comment


      • #13
        Originally posted by oleid View Post

        On that matter: how do you currently profit from io_uring without *directly* using low level C apis? Does boost/asio, for example, already support io_uring?
        Boost/asio has io_uring backend since 1.78.0:

        Comment


        • #14
          Originally posted by bug77 View Post
          This is well out of my area of expertise, but if I understood correctly, you don't. At least not directly. This more happening within the kernel, while you keep calling the same kernel APIs you are used to.
          Sorry, that's not correct. To profit from io_uring, you must use the corresponding syscalls -- either directly, or via a userspace wrapper library, like liburing.

          https://git.kernel.dk/cgit/liburing/tree/README

          That README contains a link to an introductory doc. It's worth skimming through, even if you have no intention of using it.


          BTW, my experience with boost::asio is that it's rather heavy-weight to make sense for high-IOPS io_uring scenarios. It's designed more with network communication latencies in mind. Also, it traditionally doesn't scale over threads terribly well.

          Comment


          • #15
            Originally posted by mojc View Post
            Boost/asio has io_uring backend since 1.78.0:
            If you read down near the bottom, the author states:

            As you can see, the benchmark completes faster with io_uring. However, this does not include the additional CPU usage associated with io_uring's kernel worker threads, which results in higher overall CPU usage than epoll.

            And the benefit is a 38% improvement. Not bad, but I do hope the quoted numbers were median figures and not best/worst of the io_uring and epoll versions, respectively. He also mentions other caveats you should definitely read, if you're thinking of using it.

            Importantly, note that his benchmark is using socket communication via pipe(). If he were doing conventional file I/O, epoll() wouldn't even be an option.

            Comment


            • #16
              Originally posted by coder View Post
              Sorry, that's not correct. To profit from io_uring, you must use the corresponding syscalls -- either directly, or via a userspace wrapper library, like liburing.

              https://git.kernel.dk/cgit/liburing/tree/README

              That README contains a link to an introductory doc. It's worth skimming through, even if you have no intention of using it.


              BTW, my experience with boost::asio is that it's rather heavy-weight to make sense for high-IOPS io_uring scenarios. It's designed more with network communication latencies in mind. Also, it traditionally doesn't scale over threads terribly well.
              Thank you. I'll make some time to read that.

              Comment


              • #17
                I bow humbly to this guys skills. Damn! So will any of this perf improvement claw back some of the perf loss from Retbleed mitigations?

                Comment


                • #18
                  Originally posted by MorrisS. View Post
                  I'm very excited on this new bunch of progresses. I hope that linux operating systems will adopt this kernel soon as possible.
                  There's almost a 100% guarantee that 5.20 / 6.0 will be the next LTS kernel which would be good for adoption down the road.

                  Comment


                  • #19
                    Originally posted by kozman View Post
                    I bow humbly to this guys skills. Damn! So will any of this perf improvement claw back some of the perf loss from Retbleed mitigations?
                    Yes he is amazing at what he does with io_uring, but no those subsystem improvments dont help with the lose of the real computing power from those software migations.

                    Comment


                    • #20
                      Originally posted by erniv2 View Post

                      Yes he is amazing at what he does with io_uring, but no those subsystem improvments dont help with the lose of the real computing power from those software migations.
                      Well, some of the mitigations of the past years made syscalls a lot more expensive, and io_uring reduces the need to do so many syscalls. So it can help directly, but whether it's significant in any way depends on workload of course.

                      Comment

                      Working...
                      X