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) ?
-- viresh