search

ColinIanKing / stress-ng

This is the stress-ng upstream project git repository. stress-ng will stress test a computer system in various selectable ways. It was designed to exercise various physical subsystems of a computer as well as the various operating system kernel interfaces.
https://github.com/ColinIanKing/stress-ng
GNU General Public License v2.0
1.82k stars 290 forks source link

matrix stressor with max size will execute extremely longer than expected time. #403

Closed woodrow-shen closed 5 months ago

woodrow-shen commented 5 months ago

Test environment:

When the following command is executed with matrix stressor, it works well: 

$ stress-ng --matrix 1 -t 0 --matrix-ops 9 --verbose --matrix-size 8192 --metrics-brief
stress-ng: debug: [3607855] invoked with 'stress-ng --matrix 1 -t 0 --matrix-ops 9 --verbose --matrix-size 8192 --metrics-brief' by user 1000 'u'
stress-ng: debug: [3607855] stress-ng 0.18.00
stress-ng: debug: [3607855] system: Linux u-NUC7i5BNH 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64, gcc 11.4.0, glibc 2.35, little endian
stress-ng: debug: [3607855] RAM total: 15.5G, RAM free: 2.0G, swap free: 749.0M
stress-ng: debug: [3607855] temporary file path: '/home/u/github/stress-ng', filesystem type: ext2 (32361686 blocks available)
stress-ng: debug: [3607855] CPUs have 9 idle states: C1, C10, C1E, C3, C6, C7s, C8, C9, POLL
stress-ng: debug: [3607855] 4 processors online, 4 processors configured
stress-ng: info:  [3607855] setting to a 0 secs run per stressor
stress-ng: debug: [3607855] CPU data cache: L1: 32K, L2: 256K, L3: 4096K
stress-ng: debug: [3607855] cache allocate: shared cache buffer size: 4096K
stress-ng: info:  [3607855] dispatching hogs: 1 matrix
stress-ng: info:  [3607855] note: 4 cpus have scaling governors set to powersave and this may impact performance; setting /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor to 'performance' may improve performance
stress-ng: debug: [3607855] starting stressors
stress-ng: debug: [3607855] 1 stressor started
stress-ng: debug: [3607856] matrix: [3607856] started (instance 0 on CPU 1)
stress-ng: debug: [3607856] matrix: using method 'all' (x by y)
stress-ng: debug: [3607856] matrix: [3607856] exited (instance 0 on CPU 3)
stress-ng: debug: [3607855] matrix: [3607856] terminated (success)
stress-ng: debug: [3607855] metrics-check: all stressor metrics validated and sane
stress-ng: metrc: [3607855] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: metrc: [3607855]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: metrc: [3607855] matrix                9      2.06      1.84      0.22         4.36           4.36
stress-ng: info:  [3607855] skipped: 0
stress-ng: info:  [3607855] passed: 1: matrix (1)
stress-ng: info:  [3607855] failed: 0
stress-ng: info:  [3607855] metrics untrustworthy: 0
stress-ng: info:  [3607855] successful run completed in 2.07 secs

However, if --matrix-ops just increases by 1, which set --matrix-ops 10. In case it will get very longer execution than I expected:

$ stress-ng --matrix 1 -t 0 --matrix-ops 10 --verbose --matrix-size 8192 --metrics-brief
stress-ng: debug: [3607932] invoked with 'stress-ng --matrix 1 -t 0 --matrix-ops 10 --verbose --matrix-size 8192 --metrics-brief' by user 1000 'u'
stress-ng: debug: [3607932] stress-ng 0.18.00
stress-ng: debug: [3607932] system: Linux u-NUC7i5BNH 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64, gcc 11.4.0, glibc 2.35, little endian
stress-ng: debug: [3607932] RAM total: 15.5G, RAM free: 3.0G, swap free: 749.0M
stress-ng: debug: [3607932] temporary file path: '/home/u/github/stress-ng', filesystem type: ext2 (32361659 blocks available)
stress-ng: debug: [3607932] CPUs have 9 idle states: C1, C10, C1E, C3, C6, C7s, C8, C9, POLL
stress-ng: debug: [3607932] 4 processors online, 4 processors configured
stress-ng: info:  [3607932] setting to a 0 secs run per stressor
stress-ng: debug: [3607932] CPU data cache: L1: 32K, L2: 256K, L3: 4096K
stress-ng: debug: [3607932] cache allocate: shared cache buffer size: 4096K
stress-ng: info:  [3607932] dispatching hogs: 1 matrix
stress-ng: info:  [3607932] note: 4 cpus have scaling governors set to powersave and this may impact performance; setting /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor to 'performance' may improve performance
stress-ng: debug: [3607932] starting stressors
stress-ng: debug: [3607932] 1 stressor started
stress-ng: debug: [3607933] matrix: [3607933] started (instance 0 on CPU 3)
stress-ng: debug: [3607933] matrix: using method 'all' (x by y)
=> it's still under stressing after 10+ mins later.

What now makes me get confused is why matrix-ops between 9 and 10 has a obvious gap from timing.

woodrow-shen commented 5 months ago

OK, I see. the 10th ops also equals to execute stress_matrix_xy_prod function, which may really take much more time in computing product. Will close this.