On 05/03/18 15:03, Viresh Kumar wrote:
On 5 March 2018 at 17:52, Ionela Voinescu ionela.voinescu@arm.com wrote:
On 05/03/18 10:27, Viresh Kumar wrote:
From: Leo Yan leo.yan@linaro.org
The homescreen test-case shows unwanted disturbance on the big CPUs on the Hikey620 platform with Android 4.9. There are multiple reasons for that though.
I think you mean Hikey960 here, as Hikey620 has only cores with the same micro-architecture.
Sure you are correct here.
Are you able to share the test setup and results?
Nothing special in the test case really:
- I merged hikey 4.9 branch with eas-dev branch and was testing it with WALT
disabled.
- The homescreen testcase is defined here:
http://git.linaro.org/power/product-codeline.git/tree/wlauto/agendas/homescr...
enabled traces and energy measurements as well.
Traces clearly show that some tasks go for the big CPUs.
I was under the impression that in the current configuration, all boosted tasks are also prefer_idle,
We have separate tunables for them. So yes we can control prefer_idle separately I think. The same is done in the above yaml.
so I would not expect any disturbance in that case. I might be wrong, but I'm curious if you had to change the schedtune configuration in order to observe an issue.
Yeah, so the yaml disables prefer_idle in one of the test.
I was looking into the same issue and wondering if this logic should not be applied for both non-latency sensitive scenarios: selection of backup idle CPU (as you've done here) and selection of active CPU, where we would select the lowest capacity one, despite it not having the highest spare. But, I think the scenario involving choosing an active CPU is more complicated as we might want to spread tasks when boosted, rather then pack them.
Well, maybe. I will give more thought on that and see if that will make sense as well. But I didn't try it yet as that was part of the prefer_idle path, and we always prefer the big CPU there.
We have three cases in there: case A is the latency sensitive prefer_idle case, case B is the non-latency sensitive selection of backup idle CPU and case C is the selection of an active CPU for a non-latency sensitive task. We only prefer the biggest CPU for prefer-idle, only if the task is boosted as well. I was referring to case C in the comments above about the selection of a active CPU, especially the boosted, non-prefer_idle case. I would appreciate your thoughts.
In any case, all of this is highly dependent on order (bigs to littles, littles to bigs, assumptions on reserved CPUs) and although separate tunables are used to set boost and the prefer_idle flag, the odd cases of non-boosted prefer_idle tasks and non-prefer_idle boosted tasks do not always result in optimal placements. As Patrick mentioned, we're trying to find a solution in which order does not matter at all.
Ionela.
But this is a more simple case and it would benefit from a wider audience on android gerrit, especially in light of other changes that are considered for find_best_target: https://android-review.googlesource.com/q/strf
Sure, I just wanted to get basic feedback here first (reviews are much easier on email) and then post to gerrit.
-- viresh