Re: [PATCH next v1 2/2] io_uring: limit local tw done

[Jens Axboe <axboe@kernel.dk>]

On 11/21/24 8:07 AM, Pavel Begunkov wrote:
>> At least for now, there's a real issue reported and we should fix it. I
>> think the current patches are fine in that regard. That doesn't mean we
>> can't potentially make it better, we should certainly investigate that.
>> But I don't see the current patches as being suboptimal really, they are
>> definitely good enough as-is for solving the issue.
> 
> That's fair enough, but I still would love to know how frequent
> it is. There is no purpose in optimising it as hot/slow path if
> it triggers every fifth run or such. David, how easy it is to
> get some stats? We can hack up some bpftrace script

As mentioned, I don't think it's a frequent occurence in the sense that
it happens all the time, but it's one of those "if it hits, we're
screwed" cases as now we're way over budget. And we have zero limiting
in place to prevent it from happening. As such it doesn't really matter
how frequent it is, all that matters is that it cannot happen.

In terms of a different approach, eg "we can tolerate a bit more
overhead for the overrun case happening", then yeah that'd be
interesting as it may guide improvements. But the frequency of it
occuring for one case doesn't mean that it won't be a "hits 50% of the
time" for some other case. Living with a separate retry list (which is
lockless, after all) seems to me to be the least of all evils, as the
overhead is both limited and constant in all cases.

I'd rather entertain NOT using llists for this in the first place, as it
gets rid of the reversing which is the main cost here. That won't change
the need for a retry list necessarily, as I think we'd be better off
with a lockless retry list still. But at least it'd get rid of the
reversing. Let me see if I can dig out that patch... Totally orthogonal
to this topic, obviously.

-- 
Jens Axboe