Home | History | Annotate | only in /external/ltp/testcases/kernel/controllers/cpuctl
Up to higher level directory
NameDateSize
.gitignore06-Dec-2017184
cpuctl_def_task01.c06-Dec-20179.2K
cpuctl_def_task02.c06-Dec-20179.3K
cpuctl_def_task03.c06-Dec-20179.3K
cpuctl_def_task04.c06-Dec-20179.4K
cpuctl_latency_check_task.c06-Dec-20176K
cpuctl_latency_test.c06-Dec-20174.4K
cpuctl_test01.c06-Dec-201710.4K
cpuctl_test02.c06-Dec-201710.6K
cpuctl_test03.c06-Dec-20179.5K
cpuctl_test04.c06-Dec-20179.9K
cpuctl_testplan.txt06-Dec-20177.8K
Makefile06-Dec-20171.1K
parameters.sh06-Dec-20175.9K
README06-Dec-20173.1K
run_cpuctl_latency_test.sh06-Dec-20176.6K
run_cpuctl_stress_test.sh06-Dec-201712.7K
run_cpuctl_test.sh06-Dec-201710.6K

README

      1 
      2 TEST SUITE:
      3 
      4 The directory cpuctl contains the tests related to the cpu controller.
      5 There are total 10 testcases that have been added till date.
      6 More testcases are expected to be added in future.
      7 
      8 TESTS AIM:
      9 
     10 The aim of the tests is to test cpu controller functionality.
     11 
     12 FILES DESCRIPTION:
     13 
     14 cpuctl_testN.c
     15 ---------------
     16 These are the tasks to run for cpu controller testing.
     17 The tasks have been automated in the sense that they can assign themselves to
     18 the appropriate group, can modify their group shares, can migrate etc.
     19 Each task runs for an interval TIME_INTERVAL seconds and eports the total time
     20 it could run on all cpus in an interval of INTERVAL seconds. (for convinience
     21 calculate cpu time is given in % and seconds both).
     22 A task can call a library routine from libcontrollers library to calculate
     23 total amount of shares of all the groups, total number of tasks in it's group etc.
     24 And thus a task knows what is the expected cpu time it should get to run.
     25 
     26 After say n SETS it modifies it's parameters and again report the cpu
     27 usage.
     28 Maximum effort has been used to reuse the code and keep total code size low.
     29 
     30 parameters.sh
     31 ----------
     32 This file contains the functions which do setup for the test. It creates a
     33 /dev/cpuctl directory, mounts cgroup filesystem on it with cpu. It then creates
     34 a number(n) of groups in /dev/cpuctl. The cleanup function does a complete cleanup
     35 of the system.
     36 (*However most of the error scenarios ahve been tested for a sane cleanup, still if
     37 sometime it is unable to do it justt manualy execute the commands written in cleanup
     38 function)
     39 
     40 run_cpuctl_test.sh
     41 ------------------
     42 This script creates different scenarios for cpu controller testing and fires (n) tasks
     43 in different groups to run at the same time. It waits for the return status from
     44 tasks and reports test pass/fail accordingly.
     45 
     46 Makefile
     47 --------
     48 
     49 The usual makefile for this directory
     50 
     51 $LTPROOT/output/cpuctl_resultsN.txt
     52 --------------
     53 This file will be created to log the results once the test is run. It contains the test
     54 results which are numbers and following is a description which will help to understand
     55 the results.
     56 
     57 There are two common major expected outcomes of all the tests:
     58 
     59 1. A group should get cpu time in the same ratio as it's shares.
     60 
     61 2. This time should not change with the changes in share values while the ratio in those
     62    values is same.
     63 
     64 The results file are straight forward to read. To keep things very simple just look at
     65 the two fields calc:- and exp:- in % as below:
     66 
     67 CPU TIME{calc:- 60.01(s)i.e.  50.01(%) exp:- 50.00(%)}
     68 
     69 PASS/FAIL CRITERIO:
     70 ==================
     71 A major difference in the two % values is a failure of cpu controller.
     72 Also the difference between consecutive runs under similar conditions is fail.
     73 Because of some feature which is not currently developed in kernel it is not
     74 possible to create an ideal scenario and hence the decision of PASS/FAIL is
     75 not taken for all the tests at the moment. The statistics is generated in the
     76 results file and a quick look on it gives a proper understanding.
     77 
     78 NOTE: In current scenario a variation of 1-3 % is acceptable.
     79 
     80 README:
     81 --------
     82 The one you have gone through.
     83 
     84