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
next prev parent 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