[sle][functional][rt][y] - run cyclictest & hackbench tests on bare metal for Milestone RC1
|Target version:||QA - future|
- Ensure that package rt-tests is installed
- Ensure that ibmrtpkgs is installed and execute to ensure some settings such as kthread-priority, etc
- Execute cyclictest -a -n -t -p 99 -l 1000000 ( <- or more number to collect maximum latency ) for both OS
- Open another terminal and execute hackbench -l 1000000 ( <- or more number to make the system busy as long as possible )
- Do the comparison
#2 Updated by okurz about 1 year ago
- Category set to New test
- Target version set to future
@mloviska please help me understand: Why would we want to run any RT tests on bare metal for our SLE product validation? Do you have a requirement that I am not aware of or have forgotten? Please add the corresponding motivation and/or link
#4 Updated by mloviska about 1 year ago
@okurz, @riafarov: here is the email communication as promised.
On 1/30/19 11:07 AM, Jeffrey Cheung wrote:
On 1/29/19 10:56 PM, Martin Loviska wrote:
I have noticed that we used to execute preempt-test in openQA as well as we execute this test suite with every milestone build as part of regression tests.
Here you may find the test module for openQA:
Regression tests in testopia:
Since preempt-test is not properly packaged for sle15sp1 and to make it run requires few updates in make file, I would rather replace this test with something else.
If I remember well our first call regarding RT, we should ensure that upstream tests would run in SLE15SP1-RT.
Therefore shouldn't we replace preempt-test by rt-tests ?
Yes and this is a good idea. When install SLERT, SLES will be installed as well, thus the rt-test is ready for both OS. In the past, QA help to ensure the below and then run the testing for each release
(1) Ensure that package rt-tests is installed
(2) Ensure that ibmrtpkgs is installed and execute to ensure some settings such as kthread-priority, etc
(3) Execute cyclictest -a -n -t -p 99 -l 1000000 ( <- or more number to collect maximum latency ) for both OS
(3a) Open another terminal and execute hackbench -l 1000000 ( <- or more number to make the system busy as long as possible )
(4) Do the comparison
As you see that the test is quite simple, so we manually do the test but not via openQA.
Thank you and have a nice day!
#7 Updated by mloviska about 1 year ago
- Status changed from Workable to Feedback
I have found the same test case for performance testing in Testopia.
(ii) Latency Performance Testing Steps =============================== 1. Open 2 terminal sessions with "root" privilege (a) In order to create an environment which has some loading in system to get a realistic result. This can be done with another utility in the rt-tests package called hackbench. It works by creating multiple pairs of threads or processes, that pass data between themselves either over sockets or pipes. Type "hackbench -l 200000" at terminal session#1 -l => number of loops More information at https://man.cx/hackbench(8) (b) In order to execute the latency testing Type "cyclictest -Smnu -p99 -l 100000" at terminal session#2 -S => Standard SMP testing -m => lock current and future memory allocations -n => use clock_nanosleep -u => force unbuffered output for live processing -p => priority of highest prio thread -l => number of loops The result will be something like below -----------------------------------------------------------> # /dev/cpu_dma_latency set to 0us WARN: Running on unknown kernel version...YMMV policy: fifo: loadavg: 2.26 2.29 1.90 6/536 6917 T: 0 ( 6850) P:99 I:1000 C: 100000 Min: 5 Act: 12 Avg: 10 Max: 419 T: 1 ( 6851) P:99 I:1500 C: 66669 Min: 5 Act: 10 Avg: 11 Max: 382 ----------------------------------------------------------->
I would say that we are completely fine to keep our smoke test, which does ensures that cyclictest & hackbench runs successfully.