mbox series

[for-next,v4,0/7] io_uring: defer task work to when it is needed

Message ID 20220830125013.570060-1-dylany@fb.com (mailing list archive)
Headers show
Series io_uring: defer task work to when it is needed | expand

Message

Dylan Yudaken Aug. 30, 2022, 12:50 p.m. UTC
We have seen workloads which suffer due to the way task work is currently
scheduled. This scheduling can cause non-trivial tasks to run interrupting
useful work on the workload. For example in network servers, a large async
recv may run, calling memcpy on a large packet, interrupting a send. Which
would add latency.

This series adds an option to defer async work until user space calls
io_uring_enter with the GETEVENTS flag. This allows the workload to choose
when to schedule async work and have finer control (at the expense of
complexity of managing this) of scheduling.

Patches 1,2 are prep patches
Patch 3 changes io_uring_enter to not pre-run task work
Patch 4/5/6 adds the new flag and functionality
Patch 7 adds tracing for the local task work running

Changes since v3:
 - Remove optimisation to save a single unlock. Can readd this later but it
   definitely made the code significantly harder to understand.
 - Thread actual error code back through io_run* functions
 
Changes since v2:
 - add a patch to trace local task work run
 - return -EEXIST if calling from the wrong task
 - properly handle shutting down due to an exec
 - remove 'all' parameter from io_run_task_work_ctx
 
Changes since v1:
 - Removed the first patch (using ctx variable) which was broken
 - Require IORING_SETUP_SINGLE_ISSUER and make sure waiter task
   is the same as the submitter task
 - Just don't run task work at the start of io_uring_enter (Pavel's
   suggestion)
 - Remove io_move_task_work_from_local
 - Fix locking bugs

Dylan Yudaken (7):
  io_uring: remove unnecessary variable
  io_uring: introduce io_has_work
  io_uring: do not run task work at the start of io_uring_enter
  io_uring: add IORING_SETUP_DEFER_TASKRUN
  io_uring: move io_eventfd_put
  io_uring: signal registered eventfd to process deferred task work
  io_uring: trace local task work run

 include/linux/io_uring_types.h  |   3 +
 include/trace/events/io_uring.h |  29 ++++
 include/uapi/linux/io_uring.h   |   7 +
 io_uring/cancel.c               |   2 +-
 io_uring/io_uring.c             | 253 +++++++++++++++++++++++++-------
 io_uring/io_uring.h             |  29 +++-
 io_uring/rsrc.c                 |   2 +-
 7 files changed, 269 insertions(+), 56 deletions(-)


base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
prerequisite-patch-id: cb1d024945aa728d09a131156140a33d30bc268b

Comments

Jens Axboe Aug. 30, 2022, 2:30 p.m. UTC | #1
On Tue, 30 Aug 2022 05:50:06 -0700, Dylan Yudaken wrote:
> We have seen workloads which suffer due to the way task work is currently
> scheduled. This scheduling can cause non-trivial tasks to run interrupting
> useful work on the workload. For example in network servers, a large async
> recv may run, calling memcpy on a large packet, interrupting a send. Which
> would add latency.
> 
> This series adds an option to defer async work until user space calls
> io_uring_enter with the GETEVENTS flag. This allows the workload to choose
> when to schedule async work and have finer control (at the expense of
> complexity of managing this) of scheduling.
> 
> [...]

Applied, thanks!

[1/7] io_uring: remove unnecessary variable
      commit: e2f73811084cb6f4821cbe6e53bb0d9407af52f5
[2/7] io_uring: introduce io_has_work
      commit: cb0101159452eb63d0facf806e0a868963a11035
[3/7] io_uring: do not run task work at the start of io_uring_enter
      commit: 415f872f5f3aedb62bf857c6e315a88e26c08aaa
[4/7] io_uring: add IORING_SETUP_DEFER_TASKRUN
      commit: 2a23c7a52405c17183f36ef4aefb1fcf44425c2d
[5/7] io_uring: move io_eventfd_put
      commit: 488a41100f4b9d7e10f05edead4e4d6d1c0c85a9
[6/7] io_uring: signal registered eventfd to process deferred task work
      commit: 3403692af0c6d5ae826f536a2c08f4e7c0b8b163
[7/7] io_uring: trace local task work run
      commit: 73100da58e5b1f6d8ba85e134463fb2aaca59978

Best regards,