Hi Leo,
On 11/24/2015 07:55 PM, Leo Yan wrote:
Thanks for suggestion and agree. We can select CPUs with below prioirty (from high to low):
- Select CPUs in most power efficient for groups (so may be have more than one groups on SMP platform);
Let's say we are placing a small task on a big.Little system, and that small task could fit on both the big and Little cluster.
Does the above statement imply that we would not evaluate the best CPU in the big cluster? I'd think we should, in addition to the best CPU in the little cluster, and decide between those two options. This is because we can have cases where the big cluster is actually the most efficient place to run a task due to current task loads and the OPP of the little cluster.
- Select CPUs with lowest OPP to meet capacity requirement;
- Select CPUs with highest utilization (as your said, here need to try to use least one, and I think it's more suitable for rt-app cases, even rt-app-6 also will take 35% CPU's utilization when CPU run at lowest OPP);
- Select CPUs with least CPU ID;
If you think here have no obvious logic error, I will try it in next 1~2 weeks and post result after finish related testing.
Could you post your draft changes here prior to testing? It'll help ensure I'm following your proposal correctly.
...
So in this case, should consider as a global view and define some criteria:
- CPUs don't stay on lowest OPP, but system have idle CPUs;
- CPU's lower OPP can meet capacity requirement for all task's average load;
- CPU's lower OPP can meet capacity requirement for the highest load task in system.
If meet these criteria, EAS can select idle CPU from schedule group with best power efficiency.
Though I agree this may address the issue you mentioned it'd be nice to avoid adding special cases that we must test for. Do you think it's possible to solve this problem with a more generic tweak to the wake up logic like I proposed above?
After applied above logic, it may be helpful for rt-app cases, due rt-app cases have consistent load. But in reality task's instant load may change, so when several tasks is waken up with low load, then EAS will pack them. After tasks run for a while, these tasks will increase load, then EAS should detect this and spread tasks from global view.
So EAS will select best power efficient CPU for waken up task, this is purely from task's pespective. I just wander if need do one more time calculation from whole system level.
I'd like to take this with lower proirity, we can resolve the first issue based on your above suggestion :).
Sure - I'm still of the opinion that implementing the logic above would hopefully address this, because as the tasks run and grow over time they are still waking up and sleeping. As they wake up they would at some point be spread due to the preference in the above logic to utilize all CPUs at the current OPP before making a placement that would raise the OPP. But we should see for sure if you're going to be evaluating the above proposal.
cheers, Steve