Async Buffered Reads Support Yielding Promising Results
Linux I/O expert Jens Axboe who oversees the kernel's block layer and is employed by Facebook while working on IO_uring and other storage innovations has recently been working on async buffered reads support.
Axboe sent out his latest work on async buffered reads support to replace a less than ideal implementation currently for IO_uring. XFS, EXT4, and Btrfs are the file-systems initially supported by this async buffered reads but handling additional file-systems should be easily possible.
The results of this work are enticing as with a sample application doing 4G worth of random reads in 4K chunks off an EXT4 file-system, the real time to complete dropped from 12 seconds to 9 seconds. Or 73 seconds with the prior state of the kernel. But beyond shaving a few seconds off the run time compared to the current mainline state, the async buffered reads support with IO_uring dropped the CPU usage from about 82% to roughly 52%.
Those interested in Linux storage can read about this async buffered reads work via this kernel mailing list thread.
Update: The work is now queued in the Linux block tree ahead of the upcoming Linux 5.8 merge window.
Axboe sent out his latest work on async buffered reads support to replace a less than ideal implementation currently for IO_uring. XFS, EXT4, and Btrfs are the file-systems initially supported by this async buffered reads but handling additional file-systems should be easily possible.
The results of this work are enticing as with a sample application doing 4G worth of random reads in 4K chunks off an EXT4 file-system, the real time to complete dropped from 12 seconds to 9 seconds. Or 73 seconds with the prior state of the kernel. But beyond shaving a few seconds off the run time compared to the current mainline state, the async buffered reads support with IO_uring dropped the CPU usage from about 82% to roughly 52%.
Those interested in Linux storage can read about this async buffered reads work via this kernel mailing list thread.
Update: The work is now queued in the Linux block tree ahead of the upcoming Linux 5.8 merge window.
10 Comments