On 09/03/18 12:05, Patrick Bellasi wrote:
On 09-Mar 18:31, Leo Yan wrote:
Hi Chris,
On Fri, Mar 09, 2018 at 10:07:11AM +0000, Chris Redpath wrote:
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.
IMO, from a FBT standpoint nothing really change. The ultimate goal of SchedTune (like) APIs is to allow the "propagation" of user-space knowledge into kernel space... where properly defined mechanisms are in charge to do the best to satisfy user-space requirements.
Thus...
I am a bit confused for this, just as Viresh mentioned the scenario like audio playback with LCD off, usually the SoC has very well optimization for audio island, so even the minor wrongly task placement or OPP increasing can be reflected (the absolute power increasing is not big, but the relative percentage is quite high).
I might not have expressed what I meant clearly - all I was trying to say was that the heuristics in fbt are tested only with configurations where all top-app and foreground tasks have prefer_idle, all others do not. Similarly, they are tested with touch-boost increasing the schedtune boost level from the powerHAL, and no boost changes when interaction is not happening.
I was trying to make the point that if we change these situations, we might discover parts of the CPU pre-selection in fbt which do not match our existing assumptions.
... if the user-space is smart thought to know that in a certain scenario an app does not need anymore user interaction and can relax the prefer_idle hint, then I don't see any downside from the overall quality of the result.
Of course, the user-space has to be smart enough to know that a certain application with the screen off does not requires big CPUs... while there can be maybe some other scenarios where that's not true.
This just to say that I'm not convinced that the PowerHAL can take these decisions by itself, without any specific knowledge coming directly from the apps.
So I think currently we usually set the default boost margin as 10% or 20%, which is not good matching for audio playback with LCD off?
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.
I'm trying here to say I don't know if we could guarantee (for any particular device) that removing boost and prefer_idle flags from the top_app group if the screen is off will result in a different task placement than leaving it in place, although we should be able to confidently say that it will result in a lower OPP being selected.
You just have a new configuration to test and tune and I think that the ultimate result is hard to reason about with any level of confidence. It likely depends on the device, how the audio pipeline is constituted etc. etc. etc.
It occurs to me that we don't currently know how long it takes for a screen-on event to translate into an event delivered to the power HAL and then to translate into a cgroup parameter change. It seems that we should try to measure that somehow to figure out if we dare to tune-down the system when the screen is off.
I would say that we should instead be able to define a proper interface where hints can be translated into optimal heuristics implemented as mechanisms in kernel space. If the user-space "propagates" the correct hints... then we should be fine.
Just want to clarify that rather than proposal new method task classification, I want to know what's better schedtune flag setting with current task classification method.
We are working on a different model of "tasks classification". In this new model there will not be pre-defined groups of tasks and tasks moving among groups. Instead, every app will have its own group and a set of attributes which will be tuned at run-time depending on the application role and/or desired behaviors (to a certain extend).
This new model will definitively match what Leo is proposing.
And for example, if we only set boost margin after Android powerHAL receive 'interactive' hint, does this will introduce how much downgradation for UI performance?
That should be relatively simple to profile on a target like an Hikey960 where we have full access to the PowerHAL...
Yep, this is going to be device specific.