On Wed, 2021-06-16 at 16:37 +0100, Pavel Begunkov wrote: > On 6/16/21 3:44 PM, Jens Axboe wrote: > > On 6/16/21 8:01 AM, Pavel Begunkov wrote: > > > On 6/16/21 2:42 PM, Olivier Langlois wrote: > > > > On Tue, 2021-06-15 at 15:51 -0600, Jens Axboe wrote: > > > > > Ditto for this one, don't see it in my email nor on the list. > > > > > > > > > I can resend you a private copy of this one but as Pavel > > > > pointed out, > > > > it contains fatal flaws. > > > > > > > > So unless someone can tell me that the idea is interesting and > > > > has > > > > potential and can give me some a hint or 2 about how to address > > > > the > > > > challenges to fix the current flaws, it is pretty much a show > > > > stopper > > > > to me and I think that I am going to let it go... > > > > > > It'd need to go through some other context, e.g. task context. > > > task_work_add() + custom handler would work, either buf-select > > > synchronisation can be reworked, but both would rather be > > > bulky and not great. > > > > Indeed - that'd solve both the passing around of locking state > > which > > I really don't like, and make it much simpler. Just use task work > > for > > the re-insert, and you can grab the ring lock unconditionally from > > there. > > Hmm, it might be much simpler than I thought if we allocate > a separate struct callback_head, i.e. task_work, queued it > with exactly task_work_add() but not io_req_task_work_add(), > and continue with the request handler. > ok thx a lot for the excellent suggestions! I think that you have provided me everything that I need to give a shot for a second version of this patch.
