Re: [RFC PATCH 00/15] io_uring: thread identity handoff for blocking inline issue

[Gabriel Krisman Bertazi]

Jens Axboe <axboe@xxxxxxxxx> writes:

> On 9/11/26 11:33 AM, Gabriel Krisman Bertazi wrote:
>> It has the downside of still requiring fixes to every path and we need
>> to handle every new case that comes by, but it is much cleaner than
>> plumbing a nonblock flag several layers down the stack across each
>> subsystem or having subsystem-specific details in io_uring, which is
>> what we have today.  On the upper side, it is much less complex than
>> your approach. It also allow us to just back off during memory
>> allocations that would block, solving the memory allocations anywhere in
>> the submission path, not only inside ->issue(), which we discussed
>> recently on discord.
>
> I think you'll find it'll be a lot MORE complicated than my approach!
> Backing out error handling is going to be impossible in some cases,
> think file systems for example. How would those cases be handled?

I understand there are many cases where it would be impossible, most, if
not all of them, involving FS.  But I naively imagine we could back-off
those early, before we get to the critical session, without even trying
the nonblock approach, similar to what we do now, and punt to the io-wq,
which is not going away anyway.  What I'd like to solve is drop the
logic of other parts of the kernel that we need to keep in the io_uring
layer, such as which network protocols will block and which won't.

It is a hard sell, yes. And it does gives off vibes of re-editing the
PF_MEMALLOC_NORECLAIM controversy. Long term, though, it would be much
better for the kernel that can reliably handle failure and back-off than
keep going, including for predictable performance.

-- 
Gabriel Krisman Bertazi