On Wed, Mar 07, 2018 at 11:37:30AM +0530, Viresh Kumar wrote:
On 06-03-18, 11:00, Patrick Bellasi wrote:
Right, more precisely I would say that we use "prefer_idle" to flag certain tasks as being "latency sensitive". That's because they directly affect the user experience, e.g. the UI thread.
How did we conclude that the tasks that end up on the big CPUs for homescreen and audio playback are *really* latency sensitive ? Is it correct to enable prefer-idle and boost for every foreground task on the system ? Maybe the algorithm (in kernel) is all fine, and we need to categorize the tasks in a finer way ?
Even if the system is not in low-util mode (as explained by you earlier), why should such tasks hit a big CPU ever ? What user experience are they taking care of ?
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?
Thanks, Leo Yan