summaryrefslogtreecommitdiff
path: root/tools
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2019-01-18 22:56:34 -0700
committerJens Axboe <axboe@kernel.dk>2019-03-06 13:00:16 -0700
commit31b515106428b9717d2b6475b6f6182cf231b1e6 (patch)
treeef022236522e520fd3c2c4796a3c45e5b3fa3df4 /tools
parent221c5eb2338232f7340386de1c43decc32682e58 (diff)
io_uring: allow workqueue item to handle multiple buffered requests
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. Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions