Detail plans for task placement testing on big.LITTLE MP
big.LITTLE MP will schedule long-running, light workloads on a7 while bringing in a15 cores for shorter duration, cpu intensive tasks. We need to create or find a set of tests for ensuring that this works properly and automate them as part of the big.LITTLE testing effort.
Blueprint information
- Status:
- Complete
- Approver:
- Paul Larson
- Priority:
- Medium
- Drafter:
- Paul Larson
- Direction:
- Approved
- Assignee:
- Naresh Kamboju
- Definition:
- Superseded
- Series goal:
- Accepted for trunk
- Implementation:
-
Unknown
- Milestone target:
-
backlog
- Started by
- Completed by
- Naresh Kamboju
Related branches
Related bugs
| Bug #1082271: bL-MP open test build missing task-placement-tests | Fix Released |
| Bug #1083090: dd failed on ikshackbox master | Fix Released |
Sprints
Whiteboard
[asac Sep 5, 2012]: waits on sysbench, cyclicbench to land in builds.
[nkambo Sep 12, 2012]: smoke test is completed for cyclictest on Android.
[nkambo Sep 12, 2012]: sysbench, cyclictests have been delivered from [pundiramit] Android team.
[nkambo Sep 17, 2012]: By using sysbench and cyclictests we can create below listed loads and time interval of running. while running these tests we need to identify mechanism to instrument the kernel to identify and print, the cluster number and core number, duration on test on each core. this instrumentation has been planned at project level. so need to communicate with development team and identify the best tools to trace cpu, threads and time.
[nkambo Sep 19, 2012]: android team is exploring the option of using trace-cmd to get cpu and thread debug information. which could helps in task migration among cores and clusters.
[nkambo Sep 22, 2012]: private git created.
[nkambo Sep 22, 2012]: Synthetic tasks development is over.
[nkambo Sep 24, 2012]:
I have developed framework which will detects, given process execution on all core and will display number of executions and percentage of execution on each core. this will make which core is handled the job most is it little core or big core. according this we can verify heavy loads should run most of the percentage on big and low and medium should run most of the time on little cores.
I am in the middle of investigating how to map core numbers vs bigLITTLE? core number are different in case of TC2 and vexpress-RTSM.
After getting answer to this question we can implement PASS/FAIL for each test case.
[nkambo Sep 26, 2012]:
All work items are addressed.
[nkambo Sep 26, 2012]:
Added new test entry "task_placement" in lava-android-test.
[nkambo Oct 02, 2012] :
Blocked: Since BL MP build do not have support for bl-arm-freq drivers. Without this driver we can not make logical cores to run on big and little frequencies. so test is not completed on Fastmodels.
Testing on Hardware should be done once i receive TC2 Tiles H/W.
[nkambo nov 1, 2012] :
Test Execution on Android and Test Execution on Ubuntu are blocked because of above reasons.
[nkambo nov 19, 2012]:
I have a plan to execute this test suite on remote TC2 board.
[nkambo nov 23, 2012]:
test cases are missing in the bLMP open test build. the bug has been reported.
https:/
after this bug fixed. I will resume testing.
[nkambo Dec 2, 2012]
Android test build is broken, build is failed. where the test binaries were included.
https:/
[nkambo Jan 30 2012]
This blue print is not more valid. because of below reasons:
Basil wrote:
Review points on task-placement tests
Hi Naresh,
I looked at the task placement tests you shared. The following is my first cut understanding of the approach you seem to have took and some review inputs.
You are using sysbench and cyclictest as the ‘workloads’. You seem to get the trace data and then determine the amount of time these process spent on the big vs little domain CPUs and then determine the pass fail based on this factor.
Few observations I have which I am not sure of are noted below::
a) For short running tests you are defining low / medium / heavy load characteristics based on
a. Low – cyclictest is used
b. Medium – sysbench with test mode for threads
c. Heavy – sysbench with test mode for cpu
b) For long running tests you are defining low / medium /heavy load characteristics based on
a. Low – cyclictest is used
b. Medium – cyclictest with larger number of worker threads and sysbench with test mode for threads
c. Heavy – sysbench with test mode for cpu and very high cpu-max-prime
c) For load characteristic moving from heavy to low you have
a. Sysbench with test mode for cpu and the cpu-max-prime is being reduced from 200000 to 10000 across 5 steps (by steps i mean separate sysbench runs)
b. Sysbench with test mode for threads and thread-yields is reduced from 1000 to 100 across 5 steps (by steps i mean separate sysbench runs)
d) For load characteristic moving from low to heavy you have
a. Sysbench with test mode for cpu and cpu-max-prime is being increased from 10000 to 200000 across 5 steps (I believe there is a copy paste error in this script because it actually steps through 200000 to 10000)
b. Sysbench with test mode for threads and thread-yields is increased from 100 to 1000 across 5 steps
I had a quick discussion with Chris and it is of the opinion that we cannot confidently define the load patterns like this, because for sysbench even for a cpu-max-prime of 100 it could start with little domain and quickly move to big domain CPU.
Also you seem to have 8 / 16/ 32/ 64 worker threads created and Chris was saying that the each of the threads in readyQ would be adding the to the load contribution. So more number of worker threads than the number of CPU cores are candidates which would push the upmigration path. We might have to rebase the approach based on the number of cores on TC2 and calibrate these tests.
[nkambo Jan 20 2012]
this test suite is not more valid.
these synthetic work load generation has been taken care in bL MP scheduler test suite.
scheduler test development work is in progress, which can be tracked from below blueprint
https:/
https:/
https:/
Meta:
Headline: Linaro big.LITTLE MP test plan includes tests for task placement
Acceptance: Test plan updated with details on the tests that will be run, and automated test scripts exist that will work on android and ubuntu for task placement
Roadmap id: CARD-196
Scenarios for synthetic tasks:
* Short running, light load
* Short running, medium load
* Short running, heavy load
* long running, light load
* long running, medium load
* long running, heavy load
* long running, starts light, ends heavy
* long running, starts heavy, ends light
* long running, cycles between heavy and light load
Work Items
Work items:
Investigate task placement mechanisms in big.LITTLE MP: DONE
Investigate cyclictest and sysbench scenarios: DONE
Write details for the tests that will be needed in the test plan: DONE
Create scripts to automate the testing: DONE
Script a way to determine task placement: DONE
Create scenarios for synthetic tasks (see whiteboard): DONE
"task-placement
[vishalbhoj] Android build to be fixed. https:/
Test Execution on Android : TODO
[dpigott] bL MP ubuntu boots on hackbox: DONE
Test Execution on Ubuntu : TODO
