I have been focusing on making stress-ng more portable so it can build with various versions of clang and gcc as well as run against a wide range of kernels. The portability shims and config detection added to stress-ng allow it to build and run on a wide range of Linux systems, as well as GNU/HURD, Minix, Debian kFreeBSD, various BSD systems, OpenIndiana and OS X.
Enabling stress-ng to work on a wide range of architectures and kernels with a range of compiler versions has helped me to find and fix various corner case bugs. Also, static analysis with a various set of tools has helped to drive up the code quality. As ever, I thoroughly recommend using static analysis tools on any project to find bugs.
Since V0.08.09 I've added the following stressors:
- inode-flags - (using the FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctl, see ioctl_iflags(2) for more details.
- sockdiag - exercise the Linux sock_diag netlink socket diagnostics
- branch - exercise branch prediction
- swap - exercise adding and removing variously sized swap partitions
- ioport - exercise I/O port read/writes to try and cause CPU I/O bus delays
- hrtimers - high resolution timer stressor
- physpage - exercise the lookup of a physical page address and page count of a virtual page
- mmapaddr - mmap pages to randomly unused VM addresses and exercise mincore and segfault handling
- funccall - exercise function calling with a range of function arguments types and sizes, for benchmarking stack/CPU/cache and compiler.
- tree - BSD tree (red/black and splay) stressor, good for exercising memory/cache
- rawdev - exercise raw block device I/O reads
- revio - reverse file offset random writes, causes lots of fragmentation and hence many file extents
- mmap-fixed - stress fixed address mmaps, with a wide range of VM addresses
- enosys - exercise a wide range of random system call numbers that are not wired up, hence generating ENOSYS errors
- sigpipe - stress SIGPIPE signal generation and handling
- vm-addr - exercise a wide range of VM addresses for fixed address mmaps with thorough address bit patterns stressing
As ever, patches for fixes and improvements are always appreciated. Keep on stressing!
Thanks Coling for your update in this excellent tool!!!
ReplyDeleteI have a question, it's possible to run more of 4096 workers? With this test:
stress-ng --cpu 5132 --vm 1 --timeout 5m --metrics-briefstress-ng --cpu 5132 --vm 1 --timeout 5m --metrics-brief the result is:
Number of cpu workers must be between 0 and 4096
I modified the Hardware limit for my actual user:
Originally dates:
ulimit -Ha
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 8254097
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
And modified dates:
ulimit -Ha
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 8254097
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 8000
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
But the stress process still showing Number of cpu workers must be between 0 and 4096. Is this a expected output?
Yes, set STRESS_PROCS_MAX in stress-ng.h to the value you want, and rebuild.
DeleteI've just doubled it to 8192 and pushed it to the repository
DeleteExcellent, many thanks Sir
DeleteExcellent, thanks Colin!
ReplyDelete