Re: [PATCH 18/19] io_uring: allow workqueue item to handle multiple buffered requests

[Hannes Reinecke <hare@suse.de>]

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@kernel.dk>
> ---
>   fs/io_uring.c | 269 ++++++++++++++++++++++++++++++++++++++++----------
>   1 file changed, 218 insertions(+), 51 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.com>

Cheers,

Hannes