On 2/9/19 10:13 PM, Jens Axboe wrote:
Right now we punt any buffered request that ends up triggering an -EAGAIN to an async workqueue. This works fine in terms of providing async execution of them, but it also can create quite a lot of work queue items. For sequentially buffered IO, it's advantageous to serialize the issue of them. For reads, the first one will trigger a read-ahead, and subsequent request merely end up waiting on later pages to complete. For writes, devices usually respond better to streamed sequential writes. Add state to track the last buffered request we punted to a work queue, and if the next one is sequential to the previous, attempt to get the previous work item to handle it. We limit the number of sequential add-ons to the a multiple (8) of the max read-ahead size of the file. This should be a good number for both reads and wries, as it defines the max IO size the device can do directly. This drastically cuts down on the number of context switches we need to handle buffered sequential IO, and a basic test case of copying a big file with io_uring sees a 5x speedup. Signed-off-by: Jens Axboe <axboe@xxxxxxxxx> --- fs/io_uring.c | 269 ++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 218 insertions(+), 51 deletions(-)
Reviewed-by: Hannes Reinecke <hare@xxxxxxxx> Cheers, Hannes
