From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring Mailing List <[email protected]>,
GNU/Weeb Mailing List <[email protected]>,
Tea Inside Mailing List <[email protected]>,
Alviro Iskandar Setiawan <[email protected]>,
Alviro Iskandar Setiawan <[email protected]>,
Ammar Faizi <[email protected]>,
Nugra <[email protected]>
Subject: [PATCH liburing v1 0/4] Refactor arch dependent code and x86-64 improvement
Date: Fri, 11 Feb 2022 22:57:49 +0700 [thread overview]
Message-ID: <[email protected]> (raw)
Hi,
We have many #ifdef/#endif in syscall.h since nolibc support is added.
This series tries to clean them up, separate the definitions into
smaller more manageable pieces.
Also, optimize function call for x86-64. Avoid libc function call for
syscall even if CONFIG_NOLIBC is disabled. If this patchset is applied,
CONFIG_NOLIBC is still meaningful, we may still use libc for malloc(),
free() and memset().
New directory structure for arch
==================================
1) src/arch/generic
This contains wrappers based on libc that can be used for all archs.
2) src/arch/x86
This contains x86 specific code.
In the future, more architecture specific code can be added. Currently,
architectures other than x86-64 will use code from src/arch/generic.
Technical Explanation
======================
There are 4 patches in this series.
Patch 1
#########
This is a preparation for refactoring the syscall wrappers.
This creates a new file src/arch/generic/syscall.h. This file contains
libc syscall wrappers for architectures that don't have arch specific
code. In the next patches, we will include this file from src/syscall.h.
It aims to reduce the usage of #ifdef/#endif that occurs in every
function in src/syscall.h file. Also, it will make the arch specific
code structure cleaner and easier to manage.
Patch 2
#########
There are 3 things in this patch (a, b, c):
a) Remove all ____sys* and uring_* functions from src/syscall.h. We
will define them in the src/arch/* files, so we can avoid many
#ifdef/#endif.
b) Rename all __arch_impl_* functions in src/arch/x86/syscall.h with
____sys* and uring_* to support point (1).
c) Always use arch specific code for x86-64 syscalls, even with
CONFIG_NOLIBC disabled. For other archs, currently, will still
use the libc wrappers (we provided it in src/arch/generic*).
Major changes happen in point (c). We will always use inline assembly
for invoking syscall for x86-64. Reasoning:
1. It reduces function calls.
------------------------------
If we use libc, we need to call syscall(2) function and deal with a
global state via errno macro (errno macro will expand to a
function call too).
If we use inline Assembly, we eliminate many functions calls, we
don't need to use errno or any global state anymore as it will
just directly return error code that we can check with a simple
comparison.
2. Allow the compiler to reuse caller clobbered registers.
-----------------------------------------------------------
By the rule of System V ABI x86-64, a function call clobbers %rax,
%rdi, %rsi, %rdx, %rcx, %r8, %r9, %r10 and %r11. On Linux, syscall
only clobbers %rax, %rcx and %r11. But since libc syscall(2) wrapper
is a function call, the compiler will always miss the opportunity
to reuse those clobbered registers. That means it has to preserve
the life values on the stack if they happen to be in the clobbered
registers (that's also extra memory access).
By inlining the syscall instruction, the compiler has an opportunity
to reuse all registers after invoking syscall, except %rax, %rcx and
%r11.
3. Smaller binary size.
------------------------
Point (1) and (2) will also reduce the data movement, hence smaller
Assembly code, smaller binary size.
4. Reduce %rip round trip to libc.so.
--------------------------------------
Call to a libc function will make the %rip jump to libc.so memory
area. This can have extra overhead and extra icache misses in some
scenario. If we inline the syscall instruction, this overhead can
be removed.
Patch 3
#########
This takes care of lib.h header file, split it into generic and arch
specific.
Patch 4
#########
Change all syscall function name prefix to __sys.
Instead of using uring_mmap, uring_close, uring_madvise, etc. Let's
use __sys_mmap, __sys_close, __sys_madvise, etc. That looks better
convention for syscall function name like what we do with
__sys_io_uring* functions.
Cc: Nugra <[email protected]>
Signed-off-by: Alviro Iskandar Setiawan <[email protected]>
Signed-off-by: Ammar Faizi <[email protected]>
---
Alviro Iskandar Setiawan (2):
arch/generic: Create arch generic syscall wrappers
arch/x86, syscall: Refactor arch specific and generic syscall wrappers
Ammar Faizi (2):
lib.h: Split off lib header for arch specific and generic
Change all syscall function name prefix to __sys
src/arch/generic/lib.h | 21 +++++
src/arch/generic/syscall.h | 87 +++++++++++++++++++++
src/arch/x86/lib.h | 20 +++--
src/arch/x86/syscall.h | 57 ++++++++------
src/lib.h | 45 +++++------
src/nolibc.c | 4 +-
src/register.c | 4 +-
src/setup.c | 22 +++---
src/syscall.h | 155 ++++++-------------------------------
9 files changed, 214 insertions(+), 201 deletions(-)
create mode 100644 src/arch/generic/lib.h
create mode 100644 src/arch/generic/syscall.h
base-commit: 90a4da4d51f137229a2ef39b25880d81adfcb487
--
2.32.0
next reply other threads:[~2022-02-11 15:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 15:57 Ammar Faizi [this message]
2022-02-11 15:57 ` [PATCH liburing v1 1/4] arch/generic: Create arch generic syscall wrappers Ammar Faizi
2022-02-11 15:57 ` [PATCH liburing v1 2/4] arch/x86, syscall: Refactor arch specific and " Ammar Faizi
2022-02-11 15:57 ` [PATCH liburing v1 3/4] lib.h: Split off lib header for arch specific and generic Ammar Faizi
2022-02-11 15:57 ` [PATCH liburing v1 4/4] Change all syscall function name prefix to __sys Ammar Faizi
2022-02-11 16:39 ` [PATCH liburing v1 0/4] Refactor arch dependent code and x86-64 improvement Jens Axboe
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[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