The cpucontroller testplan includes a complete set of testcases that test the cpu controller in different scenarios. **These testcases test the cpu controller under flat hierarchy.** General Note:- ============ How to calculate expected cpu time: Say if there are n groups then total share weight = grp1 share + grp2 shares +......upto n grps then expected time of any grp (say grp1) =100 * (grp1 share) /(total share weight) % (* If there were say 2 task in a group then both task might devide the time * of this group and it would create no effect on tasks in other group. So a * task will always get time from it's group time only and will never affect * other groups share of time. * Even if task is run with different nice value it will affect the tasks in * that group only. ) !!! User need not worry about this calculation at all as the test dynamicaly calculates expected cpu time of a task and prints for each task in results file. This calculation is given for refernce to interested users. For any other information please refer to cgroup.txt in kernel documentation. TESTCASE DESCRIPTION: ==================== Test 01: FAIRNESS TEST --------------------- This test consists of two test cases. The test plan for this testcase is as below: First of all mount the cpu controller on /dev/cpuctl and create n groups. The number of groups should be > the number of cpus for checking scheduling fairness(as we will run 1 task per group). then we create say n groups. By default each group is assigned 1024 shares. The cpu controller schedules the tasks in different groups on the basis of the shares assigned to that group. So the cpu usage of a task depends on the amount of shares it's group has out of the total number of shares(no upper limit but a lower limit of 2) and the number of tasks in that group(in this case only 1). So until and unless this ratio(group A' shares/ Total shares of all groups) changes, the cpu time for this group A remains constant. Let us say we have 3 groups(1 task each) A,B,C each having 2, 4, 6 shares respectively. Hence if the tasks are running infinitely they are supposed to get 16.66%, 33.33%, 50% cpu time respectively. This test case tests that each group should get the cpu time in the same(above) ratio irrespective of the shares absolute values provided the ratio is not changed i.e. the cpu time per group should not change if we change the shares from 2, 4, 6 to 200, 400, 600 or to 20K, 40K, 60K etc (provided the working conditions do not change). Thus the scheduling is proportional bandwidth scheduling and not absolute bandwidth scheduling. This was the test and outcome for test01. For test02 the setup is kept same. Test 02 tests if the fairness persists among different runs over a period of time. So in this test more than one sets of reading are taken and the expected outcome is that the cpu time for a task should remain constant among all the runs provided the working environment is same for the test. Currently the support to create an ideal environment for all the runs is not available in the test because of some required feature in the kernel. Hence there may be some variations among different runs depending on the execution of system default tasks which can run any time. The fix for this is supposed to be merged with next release. How to view the results: ----------------------- The cpu time for each group(task ) is calculated in %. There are two outcomes of the test: 1. A group should get cpu time in the same ratio as it's shares. 2. This time should not change with the changes in share values while the ratio in those values is same. NOTE: In case 1 a variation of 1-2 % is acceptable. (here we have 1 task per group) Test 03: GRANULARITY TEST ------------------------- Granularity test with respect to shares values In this test the shares value of some of the groups is increased and for some groups is decreased. Accordingly the expected cpu time of a task is calculated. The outcome of the test is that calc cpu time must change in accordance with change in shares value. (i.e. calculated cpu time and expected cpu time should be same) Test 04: NICE VALUE TEST ------------------------- Renice all tasks of a group to -20 and let tasks in all other groups run with normal priority. The aim is to test that nice effect is within the groups and not shares are dominant over nice values. Test 05: TASK MIGRATION TEST ---------------------------- In this test for the first run the test is run with say n tasks in m groups. After first run a task is migrated from one group to another group. This task now consumes the cpu time from the new group. Test 06-08 : NUM GROUPS vs NUMBER of TASKS TEST ---------------------------------------------- In the following three testcases a total tasks are same and each task is expected to get same cpu time. Theses testcases test the effect of creating more groups on fairness.(however latency check will be done in future) Test 06: N X M (N groups with M tasks each) ------- Test 07: N*M X 1 (N*M groups with 1 task each) ------- Test 08: 1 X N*M (1 group with N*M tasks) ------- Test 09-10: STRESS TEST ---------- The next two testcases put stress on system and create a large number of groups each running a large number of tasks in it. Test 09: Heavy stress test with nice value change ------- Creates 4 windows of different NICE values. Each window runs some n groups. Test 10: Heavy stress test (effect of heavy group on light group) ------- In this test one group has very less tasks while others have large number of tasks. This tests if fairness still remains. Test 11-12: LATENCY TESTS ---------- The latency tests refer to testing if the cpu is available(within a reasonable amount of time) to a task which woke up after a sleep(), when the system is having enough load. In the following two testcases we run n(NUM_TASKS set in script) tasks as the load tasks which simply hog the cpu by doing some sqrt calculation of a number of type double. A task named latency check task is launched after these tasks. This task sleeps frequently and measures the latency as the difference b/n the actual and expected sleep durations. In case of test 12 the tasks are running under different groups created dynamically depending on the number of cpus in the machine.(min 2, else 1.5 * NUM_CPUS). The tasks migrate to their groups automatically, before they start hogging the cpu. The latency check task also runs under any of the groups. Test 11: cpuctl latency test 1 ------- This test adds one testcase for testing the latency when the group scheduler is not mounted, but compiled in kernel.(i.e. no task group is created) Test 12: cpuctl latency test 2 ------- This test adds one testcase for testing the latency when the group scheduler is mounted, and has tasks in different groups. NOTE: There is no clear consensus on the maximum latency that the scheduler should guarantee. Latency may vary from few milliseconds in normal desktops to even a minute in virtaul guests. However a latency of more than 20 ms (under normal load, as it is load dependent) is not considered good. This test is to keep an eye on the max latency in different kernel versions with respect to further development of the group scheduler. The threshold for this test is calculated based on the value exported by the kernel in /proc/sys/kernel/sched_wakeup_granularity_ns. In case the kernel is not compiled to reflect the same, we use the same logic as by the kernel. sysctl_sched_wakeup_granularity = (1 + ln(nr_cpus))*default_gran_logic. For making the allowed latency to be more practical we multiply it by 2. So even if the test may show FAIL, it may not be an actual failure. ( In all(1-10) tests calc cpu time and exp cpu time should be same Time:: calc:- calculated cpu time obtained for a running task exp:- expected time as per the shares of the group and num of tasks in group. )