On 6/12/23 5:00?PM, Gabriel Krisman Bertazi wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: > >> On 6/12/23 10:06?AM, Gabriel Krisman Bertazi wrote: >>> Jens Axboe <axboe@xxxxxxxxx> writes: >>> >>>> Add support for FUTEX_WAKE/WAIT primitives. >>> >>> This is great. I was so sure io_uring had this support already for some >>> reason. I might have dreamed it. >> >> I think you did :-) > > Premonitory! Still, there should be better things to dream about than > with the kernel code. I dunno, if it's io_uring related I'm a supporter. >>> Even with an asynchronous model, it might make sense to halt execution >>> of further queued operations until futex completes. I think >>> IOSQE_IO_DRAIN is a barrier only against the submission part, so it >>> wouldn't hep. Is there a way to ensure this ordering? >> >> You'd use link for that - link whatever depends on the wake to the futex >> wait. Or just queue it up once you reap the wait completion, when that >> is posted because we got woken. > > The challenge of linked requests, in my opinion, is that once a link > chain starts, everything needs to be link together, and a single error > fails everything, which is ok when operations are related, but > not so much when doing IO to different files from the same ring. Not quite sure if you're misunderstanding links, or just have a different use case in mind. You can certainly have several independent chains of links. >>>> 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. Features to be added >>>> later: >>> >>> One item high on my wishlist would be the futexv semantics (wait on any >>> of a set of futexes). It cannot be implemented by issuing several >>> FUTEX_WAIT. >> >> Yep, I do think that one is interesting enough to consider upfront. >> Unfortunately the internal implementation of that does not look that >> great, though I'm sure we can make that work. ? But would likely >> require some futexv refactoring to make it work. I can take a look at >> it. > > No disagreement here. To be fair, the main challenge was making the new > interface compatible with a futex being waited on/waked the original > interface. At some point, we had a really nice design for a single > object, but we spent two years bikesheding over the interface and ended > up merging something pretty much similar to the proposal from two years > prior. It turned out not to be too bad - here's a poc: https://git.kernel.dk/cgit/linux/commit/?h=io_uring-futex&id=421b12df4ed0bb25c53afe496370bc2b70b04e15 needs a bit of splitting and cleaning, notably I think I need to redo the futex_q->wake_data bit to make that cleaner with the current use case and the async use case. With that, then everything can just use futex_queue() and the only difference really is that the sync variants will do timer setup upfront and then sleep at the bottom, where the async part just calls the meat of the function. >> You could obviously do futexv with this patchset, just posting N futex >> waits and canceling N-1 when you get woken by one. Though that's of >> course not very pretty or nice to use, but design wise it would totally >> work as you don't actually block on these with io_uring. > > Yes, but at that point, i guess it'd make more sense to implement the > same semantics by polling over a set of eventfds or having a single > futex and doing dispatch in userspace. Oh yeah, would not recommend the above approach. Just saying that you COULD do that if you really wanted to, which is not something you could do with futex before waitv. But kind of moot now that there's at least a prototype. -- Jens Axboe
