To support changing compilers which is particularly useful for cross
compilation, use the defined ARCH if it exists.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
As the number of CPUs increases, the information displayed on the console
may exceed one screen. In addition, most CPU information is consistent and
redundant. Therefore, the -b parameter is added to simplify the display of
CPU information.
Besides, define numbers representing test modes as more readable variables.
Signed-off-by: Zengkai163 <zzk20210127@163.com>
To support changing compilers which is particularly useful for cross
compilation, use the defined CC if it exists.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
As the content of /proc/cpuinfo for arm64 is different from x86,
which the current getCpuInfo implementation based on, the getCpuInfo
function is basically deficient for arm64.
Refer to the id definitions in linux kernel header file for arm64 cpu,
Convert the corresponding parsing fileds(like 'Features' vs 'flags')
and add the vendor id translation to support getCpuInfo for arm64.
The code logic of the non-arm64 architecture remains unchanged.
Arm64 cpu vender id References:
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/asm/cputype.h?h=v6.13-rc5
Signed-off-by: Zengkai163 <zzk20210127@163.com>
'-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
