Announcement

Collapse
No announcement yet.

Linux Kernel To Get AIO Performance Improvements

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

  • Linux Kernel To Get AIO Performance Improvements

    Phoronix: Linux Kernel To Get AIO Performance Improvements

    The Linux Kernel A-synchronous I/O support has been receiving some performance improvements and clean-ups that should soon be merged to mainline...

    http://www.phoronix.com/vr.php?view=MTI0MTk

  • #2
    Exciting

    Sounds exciting!

    Anything asynchronous sounds good to me.

    Comment


    • #3
      Originally posted by uid313 View Post
      Sounds exciting!

      Anything asynchronous sounds good to me.
      Unfortunately, very few programs use AIO; performance improvements in it will probably not affect the average user. With that said, QEMU uses AIO, so it should benefit from this.

      Comment


      • #4
        Originally posted by ryao View Post
        Unfortunately, very few programs use AIO; performance improvements in it will probably not affect the average user. With that said, QEMU uses AIO, so it should benefit from this.
        I wonder if that means that the abysmal performance that my work system has under heavy VM I/O load in VirtualBox might improve (Windows Vista/7 guests, Linux host).

        Any time that I start/shutdown/restart a VM, my system responsiveness takes a nosedive.

        Comment


        • #5
          Originally posted by ryao View Post
          Unfortunately, very few programs use AIO; performance improvements in it will probably not affect the average user. With that said, QEMU uses AIO, so it should benefit from this.
          Why is that?

          Because it is very rare for most software to be suitable for AIO or because AIO didn't exist in the kernel, hence there weren't easy to implement AIO support?

          Maybe now, we will see more software utilizing AIO in the future. I don't know.

          Comment


          • #6
            Originally posted by Veerappan View Post
            I wonder if that means that the abysmal performance that my work system has under heavy VM I/O load in VirtualBox might improve (Windows Vista/7 guests, Linux host).

            Any time that I start/shutdown/restart a VM, my system responsiveness takes a nosedive.
            This probably would help IO response times inside your VMs, but I am not sure if you would notice any effect on the host.

            When you start a VM, Linux could evict pages from cache to make room for it, which would affect system response times. It could also be that your system is IO limited.

            Originally posted by uid313 View Post
            Why is that?

            Because it is very rare for most software to be suitable for AIO or because AIO didn't exist in the kernel, hence there weren't easy to implement AIO support?

            Maybe now, we will see more software utilizing AIO in the future. I don't know.
            The kernel's VFS layer provides AIO functions. However, writing programs that take advantage of asynchronous operations requires more effort than those using their traditional UNIX counterparts. Utilizing AIO provides no benefit unless your program is a daemon that can do other things while waiting for IO.

            Comment


            • #7
              Originally posted by Veerappan View Post
              I wonder if that means that the abysmal performance that my work system has under heavy VM I/O load in VirtualBox might improve (Windows Vista/7 guests, Linux host).

              Any time that I start/shutdown/restart a VM, my system responsiveness takes a nosedive.
              Do you have a lot of RAM?

              It took me a long time to figure it out, but I noticed on my system (32GB RAM) that the settings for VM dirty_ratio and dirty_background_ratio are not nearly low enough -- even 1 is not low enough. What seems to be happening is that during heavy write activity, the system caches writes until it has hundred of MiBs or more in the cache, then decides to write it to storage and that seems to block other processes and can cause the system to nearly freeze for seconds at a time.

              My partial solution is to use dirty_bytes and dirty_background_bytes instead. I currently set them to 96MiB and 32MiB:

              echo "100663296" > /proc/sys/vm/dirty_bytes
              echo "33554432" > /proc/sys/vm/dirty_background_bytes

              That much can be written to storage in less than a second. It seems to help. The mulitple second freezes are mostly gone.

              Comment


              • #8
                Posix AIO

                Last time I checked you had to specifically link your program against libaio to get true Linux AIO, using non standard system call io_submit(2) and friends.

                Standard POSIX AIO (aio_write(3)) on Linux is a kludge implemented by spawning blocking threads in the glibc. Red Hat and Novell rolled their own implementation of POSIX AIO on top of Linux AIO for their OSes.

                Comment


                • #9
                  Nginx, a popular high-perfomance webserver, should benefit from these patches. It has asynchronous design and it supports file AIO in Linux. Would be interesting if phoronix had tested its performance with and w/o the patches.

                  Comment


                  • #10
                    Originally posted by Need4Speed View Post
                    Last time I checked you had to specifically link your program against libaio to get true Linux AIO, using non standard system call io_submit(2) and friends.

                    Standard POSIX AIO (aio_write(3)) on Linux is a kludge implemented by spawning blocking threads in the glibc. Red Hat and Novell rolled their own implementation of POSIX AIO on top of Linux AIO for their OSes.
                    That is not a requirement. Any userland program that wishes to use AIO may use the AIO syscalls without using libaio.

                    Comment


                    • #11
                      Originally posted by ryao View Post
                      The kernel's VFS layer provides AIO functions. However, writing programs that take advantage of asynchronous operations requires more effort than those using their traditional UNIX counterparts. Utilizing AIO provides no benefit unless your program is a daemon that can do other things while waiting for IO.
                      Well would be pretty cool on Web and FTP servers.

                      Comment


                      • #12
                        Well you don't have asynchronous sendfile or splice. You don't have asynchronous stat/opendir/readdir/... as well. And the interface is not the same depending on the fd type. I don't think that AIO will work on something different from regular file.

                        Do you have any news about syslets?

                        Comment


                        • #13
                          IMHO asynchronous file I/O is still a mess on Linux.

                          As already stated in this thread the POSIX-AIO is implemented in user-space with a pool of blocking threads. The reason why it is not using the Kernel-AIO is the lack of features in AIO.

                          There are 3 reasons not to use the Kernel-AIO:
                          1. It only works with the O_DIRECT-flag, which means no buffering and very slow I/O.
                          2. Kernel-AIO needs support of the file-system in the kernel. Which file-systems are supported is a little bit of a mystery. Does CIFS or NFS support it?
                          3. When you finally use it it only runs on Linux, but not on BSD-systems.

                          I come from a windows background and I have to admit that the IO-Completion-Ports (IOCP) is a much superior API compared with what Linux has to offer. It works since Windows 2000, supports sockets and ALL kind of file-handles.
                          The Kernel-AIO moves the right direction, but the progress is very slow and hardly anybody is using it.

                          I wrote a high-performance-server on windows and wonder how I would have achieved the asynchronous file-I/O on Linux.

                          Comment


                          • #14
                            Why would you need AIO specifically - ie, why would it be better than say epoll + threads?

                            Comment


                            • #15
                              Originally posted by curaga View Post
                              Why would you need AIO specifically - ie, why would it be better than say epoll + threads?
                              Because epoll, select and poll only works properly with sockets and not with files on Linux.

                              Having blocking threads doing the read/write operations does not scale.
                              An asynchronous reactor- or proactor-pattern is a much better approach.

                              Comment

                              Working...
                              X