| Age | Commit message (Collapse) | Author |
|---|
|
Include <atomic> instead of <stdatomic.h> if built with a C++ compiler.
Fixes: b9c0bf79aa87 ("src/include/liburing/barrier.h: Use C11 atomics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
This patch fixes the following class of clang compiler errors:
include/liburing.h:150:3: error: address argument to atomic operation must be a
pointer to _Atomic type ('unsigned int *' invalid)
io_uring_smp_store_release(cq->khead, *cq->khead + nr);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: b9c0bf79aa87 ("src/include/liburing/barrier.h: Use C11 atomics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Instead of using a combination of open-coding atomic primitives and using
gcc builtins, use C11 atomics for all CPU architectures. Note: despite their
name, atomic_*() operations do not necessarily translate into an atomic
instruction. This patch changes the order of the instructions in e.g.
io_uring_get_sqe() but not the number of instructions generated by gcc 10
on x86_64:
Without this patch:
0x0000000000000360 <+0>: mov 0x44(%rdi),%eax
0x0000000000000363 <+3>: lea 0x1(%rax),%edx
0x0000000000000366 <+6>: mov (%rdi),%rax
0x0000000000000369 <+9>: mov (%rax),%eax
0x000000000000036b <+11>: mov 0x18(%rdi),%rcx
0x000000000000036f <+15>: mov %edx,%esi
0x0000000000000371 <+17>: sub %eax,%esi
0x0000000000000373 <+19>: xor %eax,%eax
0x0000000000000375 <+21>: cmp (%rcx),%esi
0x0000000000000377 <+23>: ja 0x38d <io_uring_get_sqe+45>
0x0000000000000379 <+25>: mov 0x10(%rdi),%rax
0x000000000000037d <+29>: mov (%rax),%eax
0x000000000000037f <+31>: and 0x44(%rdi),%eax
0x0000000000000382 <+34>: mov %edx,0x44(%rdi)
0x0000000000000385 <+37>: shl $0x6,%rax
0x0000000000000389 <+41>: add 0x38(%rdi),%rax
0x000000000000038d <+45>: retq
With this patch applied:
0x0000000000000360 <+0>: mov 0x44(%rdi),%eax
0x0000000000000363 <+3>: lea 0x1(%rax),%edx
0x0000000000000366 <+6>: mov (%rdi),%rax
0x0000000000000369 <+9>: mov %edx,%esi
0x000000000000036b <+11>: mov (%rax),%eax
0x000000000000036d <+13>: sub %eax,%esi
0x000000000000036f <+15>: xor %eax,%eax
0x0000000000000371 <+17>: mov 0x18(%rdi),%rcx
0x0000000000000375 <+21>: cmp (%rcx),%esi
0x0000000000000377 <+23>: ja 0x38d <io_uring_get_sqe+45>
0x0000000000000379 <+25>: mov 0x10(%rdi),%rax
0x000000000000037d <+29>: mov (%rax),%eax
0x000000000000037f <+31>: and 0x44(%rdi),%eax
0x0000000000000382 <+34>: mov %edx,0x44(%rdi)
0x0000000000000385 <+37>: shl $0x6,%rax
0x0000000000000389 <+41>: add 0x38(%rdi),%rax
0x000000000000038d <+45>: retq
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
|
|
io_uring_smp_store_release() and io_uring_smp_load_acquire() currently issue
full sequentially consistent memory barriers (as opposed to release and acquire
barriers, respectively) on every architecture except x86(-64) and 64-bit ARM.
For architectures that aren't handled explicitly, we can instead use GCC's
__atomic builtins, which were introduced in GCC 4.7.
|
|
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
This missing define causes build failures on s390:
src/include/liburing.h:298: undefined reference to `io_uring_smp_mb'
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Rename the newly added arm barriers and READ/WRITE_ONCE
to avoid using popular names.
Signed-off-by: Julia Suvorova <jusual@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The names of the barriers conflict with the namespaces of other projects
when trying to directly include liburing.h. Avoid using popular global
names.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Julia Suvorova <jusual@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
making liburing on arm64 platform failed. let's support it.
root@Kylin:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux buster/sid"
root@Kylin:/# gcc -v
gcc version 8.2.0 (Debian 8.2.0-20)
root@Kylin:~/liburing# make
make[1]: Entering directory '/root/liburing/src'
cc -g -fomit-frame-pointer -O2 -Wall -Iinclude/ -c -o setup.ol setup.c
In file included from include/liburing.h:14,
from setup.c:10:
include/liburing.h: In function 'io_uring_cq_advance':
include/liburing/barrier.h:73:2: warning: implicit declaration of function 'smp_mb'; did you mean 'smp_wmb'? [-Wimplicit-function-declaration]
smp_mb(); \
^~~~~~
include/liburing.h:111:3: note: in expansion of macro 'smp_store_release'
smp_store_release(cq->khead, *cq->khead + nr);
^~~~~~~~~~~~~~~~~
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
It is not possible to install barrier.h and compat.h into the top-level
/usr/include directly since they are likely to conflict with other
software. io_uring.h could be confused with the system's kernel header
file.
Put liburing headers into <liburing/*.h> so there is no chance of
conflicts or confusion.
Existing applications continue to build successfully since the location
of <liburing.h> is unchanged. In-tree examples and tests require
modification because src/liburing.h is moved to src/include/liburing.h.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
