Hi Leo,
On 09/03/18 08:18, Leo Yan wrote:
On Wed, Mar 07, 2018 at 11:37:30AM +0530, Viresh Kumar wrote:
What about state of the system where the LCD screen is off (not displaying anything) but the platform isn't suspended, like maybe playing audio, software-updates, downloads, etc. Should all threads in such cases land on the big CPUs even if there is no display on LCD (and no UI) ?
Just ask one following question based on Viresh's:
Now Android divide tasks into several cgroup based on UI activities (top-app, foreground, backgroud and system backgroud), I just wander if we can set cgroup schedTune parameters based on different scenarios, but not based on different cgroups?
For example, when Android have hints for 'interactive'/camera/video, we can set schedtune.boost/prefer_idle for top-app & foreground cgroups; otherwise all schedtune.boost/prefer_idle can be cleared. So simply to say, we clear all schedtune flags for most time, and only set them for performance boosting scenarios (touching screen); I even think gaming scenario we don't need these tunable parameters and WALT/PELT signals have enough time to reflect the heavy workload for gaming threads.
What's your suggestion for this?
Absolutely - this falls squarely into the domain of Power HAL. I would only say that the current setup matches well the heuristics present in fbt, so when we change the assumptions about task classification and schedtune flags, we will have a new optimisation scenario to think about which might work well and might not - I suspect it will largely depend on the device what is suitable or not.
--Chris
Thanks, Leo Yan _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev