Announcement

Collapse
No announcement yet.

IO_uring Is Maturing Well On Linux For Faster & More Flexible I/O - Benchmarks On Linux 5.6

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

  • #11
    You can install the liburing library

    Comment


    • #12
      Originally posted by guglovich View Post
      You can install the liburing library
      Kernel support has to be there, and then apps have to be written to actually use it.

      In other words, if liburing isn't already installed, then manually installing it will make no difference for the performance of the apps currently installed on your system.

      Comment


      • #13
        Originally posted by jrch2k8 View Post
        Please note IO_URING should not improve performance and will not improve performance, if your drive max out moving files today will max out exactly the same with IO_URING.
        Yes and no. Legacy aio only works with O_DIRECT, foregoing buffered I/O. uring works with buffered I/O. So, there will be some benefit, even in many cases where you're currently limited mostly by storage bandwidth.

        Originally posted by jrch2k8 View Post
        What IO_URING fix is I/O contention and/or latency when handling multiple request at same time simply because it can handle efficiently and asynchronously every operation independently of each other whereas AIO have to deal with threads, fences, spinlocks, queues, etc. etc .etc. which in modern hardware introduces a lot of unnecessary overhead.
        I don't know about threads, but io_uring cuts down on the number of syscalls per I/O operation, and that's a huge benefit when doing lots of IOPS on fast storage or buffered data.

        Originally posted by jrch2k8 View Post
        this will improve greatly Desktop operations responsiveness(in theory) when you have several intensive I/O operations running in parallel(like copying some files, running some DB on the background, loading some game, installing some updates, etc.)
        Hmm... I doubt that. It will reduce the syscall frequency, as mentioned above. That will provide some benefit in system load and responsiveness, though maybe not a noticeable amount in the case you described. It can also speed up individual operations, for the same reason.

        However, it's a userspace interface change. It's not actually altering how the kernel internally manages I/O. So, the performance impact won't change, whether you're doing one I/O heavy task or a lot. It's not going to have much effect on system-wide I/O scalability.

        Comment


        • #14
          Originally posted by Danny3 View Post
          And besides, I think many other stuff can happen in the same time like running an update or apt-get update or install some program, I bet the browser is also doing some reads and writes.
          Probably the system is also logging something to some files all the times.
          Taking all these combined, I think it be very nice if at least some of the programs can use this high IOPS interface and lighten the load.
          Just to emphasize the last point I made, above - this doesn't change how the kernel internally manages I/O. It's for improving I/O performance of individual apps that use it - not improving the overall I/O scalability of the kernel.

          So, might you notice a benefit if your browser (or the libraries it uses for managing it data stores) uses io_uring? Sure. Your browser might get a little more responsive and chew up a little less CPU (especially in the sys and si columns). But, that will require software changes on their part. Still, reason enough to celebrate.

          Comment


          • #15
            Originally posted by rene View Post
            and the performance compared to non AIO? AKA old fashioned blocking i/o?
            For operations on O_DIRECT files, it's going to smoke blocking calls. Of course, almost nobody does that, so...

            For buffered, sequential I/O, I'm guessing you won't see a measurable difference. ...assuming we're comparing apples-to-apples, not blocking calls vs. async io_uring with deep prefetching. And even that should only deliver a benefit, if your device prefetching parameters aren't optimized for your storage and use case.
            Last edited by coder; 08 April 2020, 05:40 AM.

            Comment


            • #16
              Originally posted by phoronix View Post
              Phoronix: IO_uring Is Maturing Well On Linux For Faster & More Flexible I/O - Benchmarks On Linux 5.6
              Thanks for the benchmarks, but I wonder what the following test results would be:

              Sequential Read -- Buffered: Yes - Direct: No - Block Size: 4 kB

              You tested this with 2 MB, and Unbuffered/Direct with 4 kB. While 2 MB/buffered is interesting, I also want to buffered/unbuffered both at 4 kB.

              Thanks.

              Comment


              • #17
                Anyone got issues with samba and io_uring? I get data loss. Doing shasum shows some files with changed data!

                Comment


                • #18
                  Originally posted by Spam View Post
                  Anyone got issues with samba and io_uring? I get data loss. Doing shasum shows some files with changed data!
                  It's a potentially complex API, depending on how you use it. I wouldn't be surprised if there are some bugs in Samba's implementation. I recommend checking their bug database, to see if others are experiencing similar issues. If not, you might consider filing a bug, yourself.

                  Comment


                  • #19
                    Yup bug reported. Seems tricky to reproduce though.

                    Comment


                    • #20
                      The Samba Bug is fixed in 4.12.3!

                      On another note. Tested with FIO the io_uring on spinning HDD's. Almost 2.5X the iops for both random read and random writes as compared to libaio. Mighty impressive!

                      Comment

                      Working...
                      X