action #47162
closed
[sle][functional][rt][y] - run cyclictest & hackbench tests on bare metal for Milestone RC1
Added by mloviska about 5 years ago.
Updated about 5 years ago.
Description
- 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
- Related to action #46874: [sle][functional][rt][y] - replace rt_preempt_test by rt-tests ( cyclictest & hackbench ) added
- 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
That is a requirement from Jeffrey and it was done in the past as he has mentioned. Basically we still need to measure how the schedulers behave.
@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:
Hello Jeffrey!
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.
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 ?
http://download.suse.de/ibs/Devel:/RTE:/SLE15SP1/standard/src/
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.
regards,
Jeffrey
Thank you and have a nice day!
Martin
- Status changed from New to Workable
mloviska will clarify if we have any overlap not to do same things twice.
- Status changed from Workable to Feedback
I have found the same test case for performance testing in Testopia.
https://bugzilla.suse.com/tr_show_run.cgi?run_id=75804
(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.
- Due date changed from 2019-02-26 to 2019-02-21
Ok, so that means we would reject this ticket?
Setting the due date of this child and therefore also the parent to the actual planned release date of the candidate.
- Status changed from Feedback to Rejected
okurz wrote:
Ok, so that means we would reject this ticket?
Agreed!
Also available in: Atom
PDF