From: Jens Axboe <axboe@kernel.dk>
To: Peter Zijlstra <peterz@infradead.org>
Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, mingo@redhat.com
Subject: Re: [PATCH 3/7] io_uring: add support for futex wake and wait
Date: Wed, 12 Jul 2023 09:05:20 -0600 [thread overview]
Message-ID: <85be94ca-3ecd-a054-1b6c-a7561bde93ba@kernel.dk> (raw)
In-Reply-To: <20230712085116.GC3100107@hirez.programming.kicks-ass.net>
On 7/12/23 2:51?AM, Peter Zijlstra wrote:
> On Tue, Jul 11, 2023 at 06:47:01PM -0600, Jens Axboe wrote:
>> Add support for FUTEX_WAKE/WAIT primitives.
>>
>> IORING_OP_FUTEX_WAKE is mix of FUTEX_WAKE and FUTEX_WAKE_BITSET, as
>> it does support passing in a bitset.
>>
>> Similary, IORING_OP_FUTEX_WAIT is a mix of FUTEX_WAIT and
>> FUTEX_WAIT_BITSET.
>>
>> FUTEX_WAKE is straight forward, as we can always just do those inline.
>> FUTEX_WAIT will queue the futex with an appropriate callback, and
>> that callback will in turn post a CQE when it has triggered.
>>
>> Cancelations are supported, both from the application point-of-view,
>> but also to be able to cancel pending waits if the ring exits before
>> all events have occurred.
>>
>> This is just the barebones wait/wake support. PI or REQUEUE support is
>> not added at this point, unclear if we might look into that later.
>>
>> Likewise, explicit timeouts are not supported either. It is expected
>> that users that need timeouts would do so via the usual io_uring
>> mechanism to do that using linked timeouts.
>>
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
> I'm not sure I'm qualified to review this :/ I really don't know
> anything about how io-uring works. And the above doesn't really begin to
> explain things.
It's definitely catered to someone who knows how that works already, I
feel like it'd be a bit beyond the scope of a commit message like that
to explain io_uring internals. Then we'd have to do that every time we
add a new request type.
But I can certainly expand it a bit and hopefully make it a bit clearer.
I'll do that.
>> +static void io_futex_wake_fn(struct wake_q_head *wake_q, struct futex_q *q)
>> +{
>> + struct io_futex_data *ifd = container_of(q, struct io_futex_data, q);
>> + struct io_kiocb *req = ifd->req;
>> +
>> + __futex_unqueue(q);
>> + smp_store_release(&q->lock_ptr, NULL);
>> +
>> + io_req_set_res(req, 0, 0);
>> + req->io_task_work.func = io_futex_complete;
>> + io_req_task_work_add(req);
>> +}
>
> I'm noting the WARN from futex_wake_mark() went walk-about.
True.
> Perhaps something like so?
I like that, sharing more code is always better. Should be a separate
patch though I think, or folded into patch 2. Which would you prefer?
I'll do a separate patch for now.
--
Jens Axboe
next prev parent reply other threads:[~2023-07-12 15:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 0:46 [PATCHSET 0/7] Add io_uring futex/futexv support Jens Axboe
2023-07-12 0:46 ` [PATCH 1/7] futex: abstract out futex_op_to_flags() helper Jens Axboe
2023-07-12 8:16 ` Peter Zijlstra
2023-07-12 14:59 ` Jens Axboe
2023-07-12 0:47 ` [PATCH 2/7] futex: factor out the futex wake handling Jens Axboe
2023-07-12 8:58 ` Peter Zijlstra
2023-07-12 15:02 ` Jens Axboe
2023-07-12 0:47 ` [PATCH 3/7] io_uring: add support for futex wake and wait Jens Axboe
2023-07-12 8:51 ` Peter Zijlstra
2023-07-12 15:05 ` Jens Axboe [this message]
2023-07-12 0:47 ` [PATCH 4/7] futex: add wake_data to struct futex_q Jens Axboe
2023-07-12 0:47 ` [PATCH 5/7] futex: make futex_parse_waitv() available as a helper Jens Axboe
2023-07-12 9:25 ` Peter Zijlstra
2023-07-12 15:06 ` Jens Axboe
2023-07-12 0:47 ` [PATCH 6/7] futex: make the vectored futex operations available Jens Axboe
2023-07-12 0:47 ` [PATCH 7/7] io_uring: add futex waitv Jens Axboe
2023-07-12 9:31 ` Peter Zijlstra
2023-07-12 15:10 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85be94ca-3ecd-a054-1b6c-a7561bde93ba@kernel.dk \
--to=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.