Re: [PATCH RESEND] io_uring: a small optimization for REQ_F_DRAIN_LINK

[Pavel Begunkov <asml.silence@gmail.com>]

On 11/22/2019 1:26 PM, JackieLiu wrote:
>> Not sure about that. It's 1 CMP + 1 SETcc/STORE, which works pretty fast
>> as @drain_next is hot (especially after read) and there is no write-read
>> dependency close. For yours, there is likely always 3 CMPs in the way.
>>
>> Did you benchmarked it somehow or compared assembly?
> 
> It is only theoretically possible. In most cases, our drain_link 
> and drain_next are both false, so only two CMPs are needed, and modern CPUs
> have branch predictions. Perhaps these judgments can be optimized.
> 
My bad, right, 2 CMPs in the common way.

> Your code is very nice, when I reading and understanding your code,
> I want to try if there is any other way to optimize it. 
> 
> Sometimes you don't need to reset drain_next, such as drain_link == true && 
> drain_next == true, you don't need to set below one more time.

We may think to change like below, but I'd rather rely on a compiler to
optimise it for us (i.e. knowing the target architecture). Everything
else is a really rare/slow path in my opinion, so shouldn't be of concern.

-	req->ctx->drain_next = (req->flags & REQ_F_DRAIN_LINK);
+	if (req->flags & REQ_F_DRAIN_LINK)
+		req->ctx->drain_next = true;

If the goal is to micro-optimise things, it's better to think how to
toss the whole scheme to reduce number of CMPs and memory read/writes in
the hot path, including setting REQ_F_DRAIN_LINK in submit_sqe().

Though, there are still heavier things happening around.

-- 
Pavel Begunkov