Test frequency and cluster migrations when load changes

Registered by Naresh Kamboju

Test and check if the frequency and cluster migrations happen as expected, when load changes up and down.The purpose is to verify that the feedback based governors such as the on-demand governor is properly adapted to the skewed reality when the requested frequency and the effective frequency are different. We'll have to implement some kind of correction factor based on that difference.

Blueprint information

Status:
Complete
Approver:
Alexander Sack
Priority:
Medium
Drafter:
Naresh Kamboju
Direction:
Needs approval
Assignee:
Naresh Kamboju
Definition:
Superseded
Series goal:
None
Implementation:
Informational Informational
Milestone target:
milestone icon 2013.06
Completed by
Milosz Wasilewski

Related branches

Sprints

Whiteboard

Comments from Nico [npitre] :
the purpose is to verify that the feedback based governors
such as the on-demand governor is properly adapted to the skewed reality
when the requested frequency and the effective frequency are different.
We'll have to implement some kind of correction factor based on that
difference. So the test would have to:

- Set the load on CPU0 so that it is constant at approximately 50% of
  maximum CPU capacity. The on-demand governor tries to lower the CPU
  frequency to half the top frequency in that case. Verify if that is
  what happens. We'll have to adjust this constant load so that a slow
  clock rate in the big cluster is selected.

- Slowly increase the load on CPU1 from very lightly loaded up to fully
  loaded. The load increase rate and duration of each step would have
  to be determined according to the available DVFS operating points.
  For each step:

  - Verify that the effective frequency ramps up as expected and that
    the cluster switch also takes place as expected.

  - Verify that the perceived load by the governor on CPU0 does not
    change. Even if the effective frequency of CPU0 will increase as
    CPU1 transitions to the big cluster and the load increases on CPU1,
    the governor on CPU0 must not request any other frequency as a
    result of an increase in idle time due to the correction factor.

[nkambo March 13 2013]
several changes have been committed in cpufreq drivers to cope cpufreq and cpuload, and on-demand governor affect on cpufreq according with cpuload needs to be tested. which needs to be analyzed and new test cases needs to developed and tested on big.LITTLE IKS image. which will be addressed in next March cycle.

[nkambo April 03 2013]
I did not get time to work on this blueprint in March cycle. My efforts have been went into big.LITTLE IKS testing. This will be addressed in April cycle.

[nkambo April 25 2013]
I have lately realized that, Implementation of this test required more understanding on cpufreq driver and task migration. current I am in the process of learning this and need to apply thought to implement test case this functional scenario.
Due to this reason, I would like to move this BP to next cycle.

[nkambo May 30 2013]
Currently I am in the process of learning this and need to apply thought to implement test case this functional scenario.
In this cycle i did not get much time to focus on this work. I would like to finish this task in 13.06 cycle. please move this BP to next cycle.

[nkambo June 27 2013]
Load generates for this tests are sysbench and cyclictest.
patterns we have here are
- Ensure we are having on-demand governors set.
- Select the current load of CPU this case it is CPU0 and get the CPU freq at which operating.
- Slowly increase the load and get the load and freq.
- Need to find a point at which the cluster migration happens at high load which can be confirmed by operating CPU freq.

[nkambo June 28 2013]
This work is estimated for 3 Weeks of efforts and updates on this BP will be continued on created jira BP http://cards.linaro.org/browse/QA-34

Meta:
Headline: Test frequency and cluster migrations when load changes
Acceptance : on-demand governor should act according to the load.
Roadmap id: TBD

(?)

Work Items

Work items:
Develop tests: INPROGRESS
Write scripts around : TODO
Integrate bl-agitator (for switching) while testing : TODO
Test on FM Android : TODO
Test on FM Ubuntu : TODO
Code Review: TODO
Push it in git: TODO
Test on LAVA FM Ubuntu : TODO
Test on LAVA FM Android: TODO
Review results on LAVA: TODO
push it in git: TODO

This blueprint contains Public information 
Everyone can see this information.