The global `iter` variable is incremented in a while(1) loop and read
asynchronously by a SIGALRM signal handler (report()). Without volatile,
the compiler cannot know the signal handler reads it and may optimize
away the loop or cache the value in a register.
Affected files: hanoi.c, syscall.c, pipe.c, context1.c, spawn.c, looper.c
Use %lu instead of %ld for unsigned long iteration counters in report()
functions. Using %ld for unsigned long is undefined behavior per the C
standard.
Affected files: arith.c, dhry_1.c, hanoi.c, pipe.c, syscall.c
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>
* 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
