summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2023-06-13 04:04:32 +0300
committerJens Axboe <axboe@kernel.dk>2023-09-29 11:37:08 +0300
commit8f350194d5cfd7016d4cd44e433df0faa4d4a703 (patch)
treee8f0e16b7c1c49670594b834b5c5ff248bdc29bb /Documentation
parente9a56c9325ef28d5481712e85dd5d3f8b2a68e88 (diff)
downloadlinux-8f350194d5cfd7016d4cd44e433df0faa4d4a703.tar.xz
io_uring: add support for vectored futex waits
This adds support for IORING_OP_FUTEX_WAITV, which allows registering a notification for a number of futexes at once. If one of the futexes are woken, then the request will complete with the index of the futex that got woken as the result. This is identical to what the normal vectored futex waitv operation does. Use like IORING_OP_FUTEX_WAIT, except sqe->addr must now contain a pointer to a struct futex_waitv array, and sqe->off must now contain the number of elements in that array. As flags are passed in the futex_vector array, and likewise for the value and futex address(es), sqe->addr2 and sqe->addr3 are also reserved for IORING_OP_FUTEX_WAITV. For cancelations, FUTEX_WAITV does not rely on the futex_unqueue() return value as we're dealing with multiple futexes. Instead, a separate per io_uring request atomic is used to claim ownership of the request. Waiting on N futexes could be done with IORING_OP_FUTEX_WAIT as well, but that punts a lot of the work to the application: 1) Application would need to submit N IORING_OP_FUTEX_WAIT requests, rather than just a single IORING_OP_FUTEX_WAITV. 2) When one futex is woken, application would need to cancel the remaining N-1 requests that didn't trigger. While this is of course doable, having a single vectored futex wait makes for much simpler application code. Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions