On 5/14/20 10:25 AM, Pavel Begunkov wrote: > On 14/05/2020 19:18, Pavel Begunkov wrote: >> On 14/05/2020 18:53, Jens Axboe wrote: >>> On 5/14/20 9:37 AM, Pavel Begunkov wrote: >>> Hmm yes good point, it should work pretty easily, barring the use cases >>> that do IRQ complete. But that was also a special case with the other >>> cache. >>> >>>> BTW, there will be a lot of problems to make either work properly with >>>> IORING_FEAT_SUBMIT_STABLE. >>> >>> How so? Once the request is setup, any state should be retained there. >> >> If a late alloc fails (e.g. in __io_queue_sqe()), you'd need to file a CQE with >> an error. If there is no place in CQ, to postpone the completion it'd require an >> allocated req. Of course it can be dropped, but I'd prefer to have strict >> guarantees. > > I know how to do it right for my version. > Is it still just for fun thing, or you think it'll be useful for real I/O? We're definitely spending quite a bit of time on alloc+free and the atomics for the refcount. Considering we're core limited on some workloads, any cycles we can get back will ultimately increase the performance. So yeah, definitely worth exploring and finding something that works. -- Jens Axboe
