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

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Sep 11, 2026 at 09:40:50AM -0600, Jens Axboe wrote:
 
> This series issues those requests inline in blocking mode instead, and
> only pays for the offload if the request actually blocks. But by the
> time it blocks, the submitter is deep in the kernel with the request on
> its stack, so the work can't be moved to another thread. What we can
> move is the identity. If the submitting task blocks, an idle io-wq
> worker takes over its user visible identity (tid, signal state,
> credentials, scheduling attributes, cgroup, user register state),
> finishes the io_uring_enter() call and returns to userspace as the
> submitter. The original task finishes the request as an
> io-wq worker and joins the pool. Userspace is none the wiser, hopefully,
> the same tid came back from the syscall, it's just on a different
> task_struct. 

I'm still struggling my way through this thing.

So thread T1 is doing this blocking syscall. When it actually blocks,
you hand-over the userspace identifying part to another thread T2, which
will return to userspace as if it were T1.

Is this really a hand-over, or a swap? I would imagine we not have two
threads with the same tid and all that.

Also, I'm a wee bit confused, why not swap out the kernel stack with a
io-wq worker and have the original thread return to userspace. This
seems like a better defined situation. In so far as anything here is
well defined.

Swapping the kernel state seems like a simpler endeavour than swapping
all that is or might be user visible.

> Folks that have been around a while may remember earlier
> attempts at this about 20 years ago.

That was the whole threadlet thing, right? Very hazy memories of that.
I'll have to go read that back, I'm sure I still have that in my inbox
*somewhere*.

Surely we abandoned that approach for a reason. ISTR there being some
significant ick there, much like the thing you're proposing now.

Not sure yet on how things compare. Will have to dig through that stuff
again.