[RFC PATCH 00/15] io_uring: thread identity handoff for blocking inline issue
Gabriel Krisman Bertazi
krisman at suse.de
Tue Sep 22 15:05:35 PDT 2026
Jens Axboe <axboe at kernel.dk> 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
More information about the linux-arm-kernel
mailing list