== SRU Justification BIONIC, EOAN ==
running a stressor that terminates early because it cannot be supported when using the --aggressive option and the -t option will not abort early as expected. It should terminate immediately if all the stressors have completed.
== Fix ==
Upstream fix: https://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=6523bfc9a6c146f44a7b9c71a10b6ac5b87276bb
This checks if all the stressor processes have terminated and if so it aborts the --aggressive mode loop.
== Test ==
stress-ng --aggressive --aiol 1 -t 5 -v
Should abort early. Without the fix it will run for 5 seconds if aiol is not supported. With the fix it aborts early if aiol is not supported.
== Regression Potential ==
Small, this affects just the --aggressive mode loop handler when the --agressive mode is enabled with a timeout.
-------------------------------------------------------
Discovered on 18.04 / 4.15 against both SSD and NVMe drives in this submission:
https://certification.canonical.com/hardware/201912-27596/submission/156320/test/64283/result/11844159/
Stress-NG spent 4 minutes attempting to run a stressor that "is not implemented on this system"
Running stress-ng aiol stressor for 240 seconds....
stress-ng: info: [130482] dispatching hogs: 256 aiol
stress-ng: info: [130483] stress-ng-aiol: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [130484] stress-ng-aiol: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [130485] stress-ng-aiol: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
...
stress-ng: info: [130737] stress-ng-aiol: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [130738] stress-ng-aiol: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [130482] successful run completed in 240.04s (4 mins, 0.04 secs)
This did not affect the outcome of the testing, so only a minor issue of confusing output because it actually consumed 4 minutes of runtime on something that appears to not be supported.
the command line that would have been used is found in the disk_stress_ng script in checkbox and is:
stress-ng --aggressive --verify --timeout 240 --temp-path $test_dir --aiol 0 --hdd-opts dsync --readahead-bytes 16M -k
Note, I do not have access to this hardware, it is from a remote submission.
Note this is on a system running an AMD Epyc 2 (Rome) CPU, not an Intel. I presume the AMD CPU doesn't support certain things being tested, hence the message, the question remains why once stress-ng determines that the stressor is not supported it continues attempting to test it.
Also from that system in the cpu stress test:
stress-ng: info: [18239] dispatching hogs: 256 af-alg, 256 bsearch, 256 context, 256 cpu, 256 crypt, 256 hsearch, 256 longjmp, 256 lsearch, 256 matrix, 256 qsort, 256 str, 256 stream, 256 tsearch, 256 vecmath, 256 wcs
stress-ng: info: [18240] stress-ng-af-alg: 41 cryptographic algorithms found in /proc/crypto
stress-ng: info: [18240] stress-ng-af-alg: 116 cryptographic algorithms max (with defconfigs)
stress-ng: info: [18255] stress-ng-wcs: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [18272] stress-ng-wcs: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [18289] stress-ng-wcs: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
stress-ng: info: [18306] stress-ng-wcs: this stressor is not implemented on this system: x86_64 Linux 4.15.0-72-generic gcc 7.4
...
https://certification.canonical.com/hardware/201912-27596/submission/156320/test/62532/result/11844201/
Just to clarify, which version of stress-ng is this? (stress-ng -V will show this)