Announcement

Collapse
No announcement yet.

Linux 5.20 To Support Async Buffered Writes For XFS + IO_uring For Big Performance Boost

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

  • Linux 5.20 To Support Async Buffered Writes For XFS + IO_uring For Big Performance Boost

    Phoronix: Linux 5.20 To Support Async Buffered Writes For XFS + IO_uring For Big Performance Boost

    Adding to the list of features slowly building up that will be destined for the Linux 5.20 cycle, Jens Axboe has queued up the support for async buffered writes with XFS when using IO_uring can deliver some significant performance advantages...

    https://www.phoronix.com/scan.php?pa...ing-Async-Buff

  • #2
    Impressive numbers. Does anybody know which applications/workloads would benefit from that?

    Comment


    • #3
      Good to see io_uring work bubbling up to normal filesystems.

      Comment


      • #4
        Originally posted by treba View Post
        Impressive numbers. Does anybody know which applications/workloads would benefit from that?
        Someone can correct me if I'm wrong but I'd think fairly common, ubiquitous workloads, like downloads, torrents, web browser cookies, and web browser cache writes, background activity such as logging, Steam cache, shader cache, and other disk caches would all be candidates for this improvement. If if this is the case, they'd probably be lighter and would get some quicker.

        If ext4 would benefit, that would also be awesome because that's going to benefit Steam Deck users and many distros users who stick with the default EXT4 filesystem.

        Comment


        • #5
          Originally posted by Mitch View Post

          Someone can correct me if I'm wrong but I'd think fairly common, ubiquitous workloads, like downloads, torrents, web browser cookies, and web browser cache writes, background activity such as logging, Steam cache, shader cache, and other disk caches would all be candidates for this improvement. If if this is the case, they'd probably be lighter and would get some quicker.

          If ext4 would benefit, that would also be awesome because that's going to benefit Steam Deck users and many distros users who stick with the default EXT4 filesystem.
          I don't know much about this topic, but from the article it appears to me that it will only help applications using io_uring, which I believe is still very uncommon.

          Comment


          • #6
            Originally posted by Mitch View Post

            Someone can correct me if I'm wrong but I'd think fairly common, ubiquitous workloads, like downloads, torrents, web browser cookies, and web browser cache writes, background activity such as logging, Steam cache, shader cache, and other disk caches would all be candidates for this improvement.
            I doubt that those data is already in the page cache?

            A reminder:
            To be able to use the fast path the required pages must be in the page cache, the required locks in xfs can be granted immediately and no additional blocks need to be read form disk

            The real question is: what is already in the page cache and can benefit?

            Comment


            • #7
              Originally posted by oleid View Post
              The real question is: what is already in the page cache and can benefit?
              Hmmm...I think archive tools like rsync and tar can benefit from this.

              Upon its initial read from a file, the kernel will then cache the rest of the file, so the i/os performed later might be cached.

              Both rsync and tar read the entire file or read none of them and they also perform a lot of other fs operations, such as walking through the directory, locating and creating directries, detect symlink/hardlink/special device file and create them, these operations likely will hit page cache since the inodes and metadata are likely to be cached in memory.

              Comment


              • #8
                Originally posted by NobodyXu View Post

                Hmmm...I think archive tools like rsync and tar can benefit from this.

                Both rsync and tar read the entire file ...
                The article says "when using io_uring". Neither rsync nor tar are using io_uring.
                Userland software needs to be rewritten in a particular way to use io_uring APIs (e.g. liburing) and claim benefits.

                Comment


                • #9
                  Originally posted by pkese View Post

                  The article says "when using io_uring". Neither rsync nor tar are using io_uring.
                  Userland software needs to be rewritten in a particular way to use io_uring APIs (e.g. liburing) and claim benefits.
                  I know that, but I think oleid is asking what softwares can take advantage of it if they are willing to modify their code, of which tar and rsync definitely can be counted here.

                  If we are talking about userland softwares that use io-uring...then there really isn't much to talk about since most of the softwares are not using it, even ones that do heavy I/O like database, webserver, proxy and etc.

                  Comment


                  • #10
                    Originally posted by NobodyXu View Post
                    If we are talking about userland softwares that use io-uring...then there really isn't much to talk about since most of the softwares are not using it, even ones that do heavy I/O like database, webserver, proxy and etc.
                    This would be a pretty nice opportunity for someone to start collecting a set of benchmarks of things which do use io_uring. Then, said benchmarks could be run against different kernel versions, filesystems, etc. to look at the real impact of the successive rounds of optimizations.

                    Michael, what kind of support does PTS have for defining subsets of tests? Could an io_uring subset be defined?

                    Comment

                    Working...
                    X