'-mabi=lp64d’ means that ‘long’ and pointers are 64-bit (implicitly defining ‘int’ to be 32-bit), and that floating-point values up to 64 bits wide are passed in F registers.
[1] https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html
Co-authored-by: Glenn Strauss <gstrauss@gluelogic.com>
github: closes#89
* fstime.c - Seperate r/w files for each parallel
Existing workload is using 1 read file and 1 write file for file
read/write/copy test. In multi-parallel scenario, it leads to
high file lock contention, while read/write/copy is not stressed.
This change seperates r/w files for each parallel to satisfy the
multi-parallel test purpose.
If all the parallels dup the same fd 0 and share the same file reference
count, then the f_count will meet with heavy lock contention. The syscall
cost of dup/close will occupy only a few in the test result. Allocating
one unique fd for each parallel will reduce lots of the unexpected
lock contention cost. And it will fully perform the syscall cost of
dup/close.
If the parallel number is 1, the testing result with this patch is the
same with the original one on ICX server, which is expected. If the
parallel number is large, the testing result will accurately show the
syscall cost of dup/close without the impact of data sharing.
Signed-off-by: Jiebin Sun <jiebin.sun@intel.com>
title[22] -> title[18] to match length of strings passed.
(not pretty code and ultimately title[] is src to strcpy(),
but at least have the prototype and function definition match)
According to http://man7.org/linux/man-pages/man2/getpid.2.html:
> From glibc version 2.3.4 up to and including version 2.24, the glibc
wrapper function for getpid() cached PIDs, with the goal of avoiding
additional system calls when a process calls getpid() repeatedly.
So it's not suitable to messure the system call performance through
getpid(). Directly call syscall(SYS_getpid) is more appropriate.
From glibc version 2.25, cached pid is removed to fix some bugs which
makes the testsuite wrongly report performance regression on system call.
Same issue is reported to unixbench upstream long time ago, but nobody
cares. https://github.com/kdlucas/byte-unixbench/pull/58
Signed-off-by: Yuanhong Peng <yummypeng@linux.alibaba.com>
github: closes#58
* Fix Result Report Race Condition in Pipe-based Context Switching Test
Ensure all report() calls yield correct information.
* Simplify code in Pipe-based Context Switching Test
Remove un-needed iter1 variable
Addresses "slave write failed: Broken pipe; aborting"
There are two processes that are alternating reading and writing
a sequence number of sizeof(unsigned long) size, which is 4 bytes
on 32-bit ILP32 ABI and 8 bytes on 64-bit LP64 ABI. The read/write
passing of incrementing sequence number occurs in infinite loop
until an alarm signals each process. There is a race condition
where a signal delivered to one process might close the pipes while
the second process was still attempting to read or write from the
pipes, and before the second process was interrupted with SIGALRM.
This patch fixes the race condition that occurs at the end of the
test run, after the first SIGALRM is delivered.
This patch does not address the paranoid possibility that read() or
write() of 4 or 8 bytes might theoretically be a partial read() or
write(), but that is extremely unlikely except in the case of a signal
being delivered, and the only signal expected is SIGALRM, and the
processing of SIGALRM by report() function does not return. (This
patch adds code to ignore SIGPIPE, so SIGALRM is the only expected
signal.)
github: fixes#1
const correctness
format string safety
remove assigned, but unused, variables
fix arguments to execl()
remove defined but unused warnings (for code used only by some tests)
barusan's patch mostly retains compatibility with linux, but
unconditionally used machdep instead of /proc/cpuinfo
This attempts to merge the patch without harming behaviour on linux by
detecting the darwin platform and using machdep there but restores
/proc/cpuinfo elsewhere.
