public inbox for [email protected]
 help / color / mirror / Atom feed
From: JackieLiu <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH RESEND] io_uring: a small optimization for REQ_F_DRAIN_LINK
Date: Fri, 22 Nov 2019 18:26:46 +0800	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>



> 2019年11月22日 18:05,Pavel Begunkov <[email protected]> 写道:
> 
> On 11/22/2019 9:01 AM, Jackie Liu wrote:
>> From: Jackie Liu <[email protected]>
>> 
>> We don't need to set drain_next every time, make a small judgment
>> and add unlikely, it looks like there will be a little optimization.
>> 
> 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.

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.

--
Jackie Liu

> 
>> Signed-off-by: Jackie Liu <[email protected]>
>> ---
>> resend that patch, because reject by mail-list.
>> 
>> fs/io_uring.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>> index 013e5ed..f4ec44a 100644
>> --- a/fs/io_uring.c
>> +++ b/fs/io_uring.c
>> @@ -2938,12 +2938,14 @@ static void __io_queue_sqe(struct io_kiocb *req)
>> static void io_queue_sqe(struct io_kiocb *req)
>> {
>> 	int ret;
>> +	bool drain_link = req->flags & REQ_F_DRAIN_LINK;
>> 
>> -	if (unlikely(req->ctx->drain_next)) {
>> +	if (unlikely(req->ctx->drain_next && !drain_link)) {
>> 		req->flags |= REQ_F_IO_DRAIN;
>> 		req->ctx->drain_next = false;
>> +	} else if (unlikely(drain_link)) {
>> +		req->ctx->drain_next = true;
>> 	}
>> -	req->ctx->drain_next = (req->flags & REQ_F_DRAIN_LINK);
>> 
>> 	ret = io_req_defer(req);
>> 	if (ret) {
>> 
> 
> -- 
> Pavel Begunkov


  reply	other threads:[~2019-11-22 10:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22  6:01 [PATCH liburing RESEND] Update link_drain with new kernel method Jackie Liu
2019-11-22  6:01 ` [PATCH RESEND] io_uring: a small optimization for REQ_F_DRAIN_LINK Jackie Liu
2019-11-22 10:05   ` Pavel Begunkov
2019-11-22 10:26     ` JackieLiu [this message]
2019-11-22 10:54       ` Pavel Begunkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01E7FC11-C19D-40FE-A471-5E1FAD2ED3D8@byteisland.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox