gettime: fix cpuclock-test on AMD platforms Starting with gcc 11 __sync_synchronize() compiles to lock or QWORD PTR [rsp], 0 on x86_64 platforms. Previously it compiled to an mfence instruction. See line 47 of https://godbolt.org/z/xfE18K7b4 for an example. On Intel platforms this change does not affect the result of fio's CPU clock test. But on AMD platforms, this change causes fio's CPU clock test to fail and fio to fall back to clock_gettime() instead of using the CPU clock for timing. This patch has fio explicitly use an mfence instruction instead of __sync_synchornize() in the CPU clock test code on x86_64 platforms in order to allow the CPU clock test to pass on AMD platforms. Reviewed-by: Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/r/20240227155856.5012-1-vincent.fu@samsung.com Signed-off-by: Vincent Fu <vincent.fu@samsung.com>
riscv64: get clock from `rdtime` instead of `rdcycle` `rdcycle` pseudo-instruction accesses the "cycle CSR" which holds the real count of CPU core clock cycles [1]. As this leaves room for side-channel attacks, access to this register from userland might be forbidden by the kernel, which results in a SIGILL [2]. Anyhow, it seems that the actual usage of the `get_cpu_clock` function in fio is about getting a wall-clock rather than the actual CPU core clock (for instance, x86 uses `rdtsc`), so this is technically a bug. The "time CSR" is the proper register to track time on riscv64. Also, the "time CSR" is more likely to be available from userspace and not cause a crash. [1] RISC-V ISA Section 10.1: https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf [2] https://lore.kernel.org/all/YxIzgYP3MujXdqwj@aurel32.net/T/ Signed-off-by: N. Le Roux <gilbsgilbs@gmail.com> Signed-off-by: Gilbert Gilb's <gilbsgilbert@gmail.com>
arch,lib/seqlock: implement seqlock with C++ atomic if compiled with C++ because some functions declared by <stdatomic.h> share the same names with those declared by <atomic>, for instance `kill_dependency()` is defined as a macro by <stdatomic.h>, while it is defined as a template function in <atomic>. this renders it impossible to compile an ioengine written in C++ if its source file includes both <atomic> and <fio.h>. the latter includes <stdatomic.h> via arch/arch.h. the compile error would look like: In file included from ../src/test/fio/fio_ceph_objectstore.cc:26: In file included from src/fio/fio.h:18: In file included from src/fio/thread_options.h:8: In file included from src/fio/gettime.h:7: src/fio/lib/seqlock.h:21:9: error: expected ')' seq = atomic_load_acquire(&s->sequence); ^ src/fio/arch/../lib/../arch/arch.h:47:32: note: expanded from macro 'atomic_load_acquire' atomic_load_explicit((_Atomic typeof(*(p)) *)(p), \ ^ src/fio/lib/seqlock.h:21:9: note: to match this '(' to address this issue, instead of using the functions in <stdatomic.h> to implement seqlock, use the primitives offered by C++ standard library if the source code is compiled using a C++ compiler. Signed-off-by: Kefu Chai <tchaikov@gmail.com>
flow: add ability for weight-based flow control on multiple jobs Fixes: #741 - fio how to run mix workload all 4 patterns in one job file Previously, 'flow' was used to regulate activity between 2 or more jobs with certain weight. However, the implementation was ineffective when regulating more than 2 jobs with different weights, since it relied on a single, shared counter, and was missing logic to track individual job's activity and regulate it according to it's requested weight in proportion to other jobs' requested weight and activity. This commit modifies the 'flow' functionality to track each job's activity and the total activity belonging to a 'flow_id' group. Using this new information, the 'flow' logic is then modified to regulate a job's activity in proportion to other jobs in the same group. Similar to previous behavior, the regulation is done by stalling a job's activity. New jobs joining an existing 'flow_id' group or jobs repead from said group will cause re-calibration of the weights and alter the activity as a result. For example, 3 jobs (j1,j2,j3) with weights (1:2:3) respectively will maintain activity ratio of 1:2:3. Thus, j1 will have activity of 1/6, j2 - 2/6 and j3 - 1/2. If j3 exits prematurely, the proportion is re-calibrated such that j1 will strive to have activity of 1/3 and j2 - 2/3. Re-calibration phase may cause a hiccup in the activity of one or more jobs since the new desired proportion might not be achieved quickly enough. Signed-off-by: David, Bar <bardavvid@gmail.com>
arch/arch.h: Introduce atomic_{load_acquire,store_release}() Implement atomic_load_acquire() and atomic_store_release() with C11 atomic operations. These two primitives will be used in later patches. This patch increases the minimum requirement for the compiler fio is built with from C90 to C11. Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Unify architecture io_uring syscall numbers Only Alpha is the odd one out, apart from that all architectures use the same system call number. So pull the code out arch headers, and into the generic arch header. Fixes: https://github.com/axboe/fio/issues/923 Signed-off-by: Jens Axboe <axboe@kernel.dk>