Hi Morten,
I have just read your scheduler slide in LCA2014, and have some questions which want to confirm with you. Before that, I shall say it is an impressive slide that well state the importance why scheduler change would benefit the power.
As you may also know the data from ARM's spec for A15/A7 power/performance diff: http://www.arm.com/files/downloads/big.LITTLE_Final.pdf
It shows one fact that even over one cpu, different tasks would shows different performance and power difference, as I see the programs like Dhrystone/FDCT shows different performance growth over A7 when running over A15.
So is it ok to get the cpu's power only by its current usage, like busy ratio? And don't care for its running task's type? I am not sure whether this is what your meaning presented in the slide. That is to modeling the energy diff, and move task around if shows energy benefit.
Is there any possible to also add task type impact into scheduler design?
Thanks, Lei
Hi Lei,
Sorry for the delayed reply.
On Tue, Mar 18, 2014 at 02:24:56AM +0000, Lei Wen wrote:
As you may also know the data from ARM's spec for A15/A7 power/performance diff: http://www.arm.com/files/downloads/big.LITTLE_Final.pdf
It shows one fact that even over one cpu, different tasks would shows different performance and power difference, as I see the programs like Dhrystone/FDCT shows different performance growth over A7 when running over A15.
The link appears to be dead, but if I understand correctly your concern is around the fact that tasks may experience different performance gain when running on A15 compared to A7 due to the different microarchitectures and the nature of the task.
So is it ok to get the cpu's power only by its current usage, like busy ratio? And don't care for its running task's type? I am not sure whether this is what your meaning presented in the slide. That is to modeling the energy diff, and move task around if shows energy benefit.
I agree that the task type does have an impact.
Firstly, the task instruction mix causes the task to scale differently with DVFS even on the same cpu. For example, memory bound tasks may not benefit from increasing the cpu frequency if the memory interface is already saturated. Currently, we don't detect this in Linux (scheduler or cpufreq).
Secondly, the different cpu microarchitectures of the A7 and the A15 means that A15/A7 performance scaling factor is different for different tasks. Some tasks have an instruction mix that executes very efficiently on A15 and will therefore experience great performance on the A15 compared to the A7 while other tasks will not.
In order to keep the energy model as simple as possible none of these aspects are currently included. I have intentionally started with an extremely simple model to minimize the model overhead. It will be used in critical code paths, so every bit of added complexity has to be justified. As work progresses we might realize that the model behind energy_diff() is too inaccurate and we have to add more complexity.
Remember that adding even a simple inaccurate model to the scheduler is an improvement in terms of energy awareness (given that we can do something useful with it). Currently there is no energy awareness at all and task load estimates are completely unaware of DVFS.
Is there any possible to also add task type impact into scheduler design?
There has been a few discussions about using performance counters to get a better picture of the cpu load. Even profiling individual tasks based on performance counters. It would indeed be interesting improvement to try. For now the focus for the energy aware scheduling work is to prove the that the idea works and add the necessary infrastructure.
I hope that answered your questions.
Morten
Morten,
On Tue, Mar 25, 2014 at 1:07 AM, Morten Rasmussen morten.rasmussen@arm.com wrote:
Hi Lei,
Sorry for the delayed reply.
On Tue, Mar 18, 2014 at 02:24:56AM +0000, Lei Wen wrote:
As you may also know the data from ARM's spec for A15/A7 power/performance diff: http://www.arm.com/files/downloads/big.LITTLE_Final.pdf
It shows one fact that even over one cpu, different tasks would shows different performance and power difference, as I see the programs like Dhrystone/FDCT shows different performance growth over A7 when running over A15.
The link appears to be dead, but if I understand correctly your concern is around the fact that tasks may experience different performance gain when running on A15 compared to A7 due to the different microarchitectures and the nature of the task.
So is it ok to get the cpu's power only by its current usage, like busy ratio? And don't care for its running task's type? I am not sure whether this is what your meaning presented in the slide. That is to modeling the energy diff, and move task around if shows energy benefit.
I agree that the task type does have an impact.
Firstly, the task instruction mix causes the task to scale differently with DVFS even on the same cpu. For example, memory bound tasks may not benefit from increasing the cpu frequency if the memory interface is already saturated. Currently, we don't detect this in Linux (scheduler or cpufreq).
Secondly, the different cpu microarchitectures of the A7 and the A15 means that A15/A7 performance scaling factor is different for different tasks. Some tasks have an instruction mix that executes very efficiently on A15 and will therefore experience great performance on the A15 compared to the A7 while other tasks will not.
In order to keep the energy model as simple as possible none of these aspects are currently included. I have intentionally started with an extremely simple model to minimize the model overhead. It will be used in critical code paths, so every bit of added complexity has to be justified. As work progresses we might realize that the model behind energy_diff() is too inaccurate and we have to add more complexity.
Remember that adding even a simple inaccurate model to the scheduler is an improvement in terms of energy awareness (given that we can do something useful with it). Currently there is no energy awareness at all and task load estimates are completely unaware of DVFS.
I totally agree that although it is a simple change, it is a big improvement for the whole scheduler. :)
Is there any possible to also add task type impact into scheduler design?
There has been a few discussions about using performance counters to get a better picture of the cpu load. Even profiling individual tasks based on performance counters. It would indeed be interesting improvement to try. For now the focus for the energy aware scheduling work is to prove the that the idea works and add the necessary infrastructure.
I hope that answered your questions.
Well, I shall say that my questions is well answered. :) Thanks for detailed explanation.
Regarding the performance counter aspect, is there anyone starting any related work yet?
- Lei
On Tue, Mar 25, 2014 at 01:43:30AM +0000, Lei Wen wrote:
Regarding the performance counter aspect, is there anyone starting any related work yet?
We have done some initial investigation internally a while back, but we are not actively working on it at the moment. On ARM the overhead of collecting PMU data for each task is quite low, but actually using these numbers for something useful requires some more research. We might take it up again at a later point in time.
Morten
linaro-kernel@lists.linaro.org
-
Lei Wen -
Morten Rasmussen