From: Mateusz Guzik <mjguzik@gmail.com>
To: brauner@kernel.org
Cc: viro@zeniv.linux.org.uk, jack@suse.cz,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Mateusz Guzik <mjguzik@gmail.com>
Subject: [PATCH] fs: predict no error in close()
Date: Sat, 1 Mar 2025 11:43:56 +0100 [thread overview]
Message-ID: <20250301104356.246031-1-mjguzik@gmail.com> (raw)
Vast majority of the time the system call returns 0.
Letting the compiler know shortens the routine (119 -> 116) and the fast
path.
Disasm starting at the call to __fput_sync():
before:
<+55>: call 0xffffffff816b0da0 <__fput_sync>
<+60>: lea 0x201(%rbx),%eax
<+66>: cmp $0x1,%eax
<+69>: jbe 0xffffffff816ab707 <__x64_sys_close+103>
<+71>: mov %ebx,%edx
<+73>: movslq %ebx,%rax
<+76>: and $0xfffffffd,%edx
<+79>: cmp $0xfffffdfc,%edx
<+85>: mov $0xfffffffffffffffc,%rdx
<+92>: cmove %rdx,%rax
<+96>: pop %rbx
<+97>: pop %rbp
<+98>: jmp 0xffffffff82242fa0 <__x86_return_thunk>
<+103>: mov $0xfffffffffffffffc,%rax
<+110>: jmp 0xffffffff816ab700 <__x64_sys_close+96>
<+112>: mov $0xfffffffffffffff7,%rax
<+119>: jmp 0xffffffff816ab700 <__x64_sys_close+96>
after:
<+56>: call 0xffffffff816b0da0 <__fput_sync>
<+61>: xor %eax,%eax
<+63>: test %ebp,%ebp
<+65>: jne 0xffffffff816ab6ea <__x64_sys_close+74>
<+67>: pop %rbx
<+68>: pop %rbp
<+69>: jmp 0xffffffff82242fa0 <__x86_return_thunk> # the jmp out
<+74>: lea 0x201(%rbp),%edx
<+80>: mov $0xfffffffffffffffc,%rax
<+87>: cmp $0x1,%edx
<+90>: jbe 0xffffffff816ab6e3 <__x64_sys_close+67>
<+92>: mov %ebp,%edx
<+94>: and $0xfffffffd,%edx
<+97>: cmp $0xfffffdfc,%edx
<+103>: cmovne %rbp,%rax
<+107>: jmp 0xffffffff816ab6e3 <__x64_sys_close+67>
<+109>: mov $0xfffffffffffffff7,%rax
<+116>: jmp 0xffffffff816ab6e3 <__x64_sys_close+67>
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
---
I'm looking at whacking some of the overhead the open+close cycle, this
is a side nit which popped up. I'm not going to argue about *this* patch.
fs/open.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index 3285d146b0e6..a5def5611b2f 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1579,11 +1579,14 @@ SYSCALL_DEFINE1(close, unsigned int, fd)
*/
__fput_sync(file);
+ if (likely(retval == 0))
+ return 0;
+
/* can't restart close syscall because file table entry was cleared */
- if (unlikely(retval == -ERESTARTSYS ||
- retval == -ERESTARTNOINTR ||
- retval == -ERESTARTNOHAND ||
- retval == -ERESTART_RESTARTBLOCK))
+ if (retval == -ERESTARTSYS ||
+ retval == -ERESTARTNOINTR ||
+ retval == -ERESTARTNOHAND ||
+ retval == -ERESTART_RESTARTBLOCK)
retval = -EINTR;
return retval;
--
2.43.0
next reply other threads:[~2025-03-01 10:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-01 10:43 Mateusz Guzik [this message]
2025-03-02 11:52 ` [PATCH] fs: predict no error in close() Christian Brauner
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=20250301104356.246031-1-mjguzik@gmail.com \
--to=mjguzik@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).