Hi Viresh,
On 06-Mar 15:29, Viresh Kumar wrote:
On 05-03-18, 15:59, Patrick Bellasi wrote:
I personally would really like a solution which do not depend on ordering at all. Meaning, find_best_target should work at its best independently from which CPUs we start from... maybe it can be more or less optimal staring from one CPU or another, but from a functional standpoint is should be the same.
Otherwise we will always risk to have a corner case not covered, as well as make it more difficult to get rid of the star_cpu at a certain point.
There is another thing that I wanted to ask.
With the current state of thing in the EAS-dev kernel + android userspace (cpuset configuration), we want all top-app and foreground tasks to run on the big CPUs however small they might be. That
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.
Scheduling "latency sensitive" tasks is quite similar to the mainline CFS policy, which always tries to look for an IDLE CPU when a task wakes up.
of course causes the big CPUs to wakeup unnecessarily for homescreen and audio playback usecases. And this is by design and not really a bug.
Yes, that's the mainline policy to a certain extent. That's also why we are evaluating a simple patch which replaces the case A in FBT with the mainline wakeup slow-path, which does essentially the same, although without the encoded knowledge of the reserved CPUs we have in FBT.
Is it correct to assume that we don't care about being power-efficient for these cases at all as we intentionally place these small tasks on the big CPUs ?
Good point: and the answer is yes and no.
Yes because in principle we wanna always go for an IDLE CPU to reduce the wakeup latency, and possibly for one of the CPUs reserved to "prefer_idle" tasks to reduce the chances for a prefer_idle task to be preempted in the future by another non latency sensitive task.
No, because we know that in certain specific use-cases (e.g. homescreen and audio playback) the system is such low utilized on the LITTLE side which we can still grant reasonable interactive performances by running just on the LITTLE side. The main problem is to "detect" these conditions in a use-case independent way...
I am asking as I am not sure if I should invest time to make EAS-dev kernel to be power efficient for these small foreground tasks, which is exact opposite of what our design is.
On that topic we are already developing a pretty simple solution named "low-util mode". The fundamental idea is to be able to detect at wakeup time if the system is lightly utilized and in that case relax the constraint to run on reserved CPUs to just go for the most energy efficient IDLE CPU.
Here is the implementation we have so far: https://android-review.googlesource.com/c/kernel/common/+/560340/3
which, based on our current wltests evaluation is not yet convincing on the power/performance side. Moreover, as you can see from the review comments on Gerrit, some corner cases still need to be fixed.
Some possible extensions/improvements identified so fare are: 1) playing with the threshold value 2) taking into account the boost value to detect if we're in low util mode
As a final remark, we should also consider that the above series has quite a big overlap with the series to use the mainline slow patch at wakeup (i.e. removing case A from FBT): https://android-review.googlesource.com/c/kernel/common/+/510757
Among the two series, we are more keen on giving higher priority to this last, since it will contribute to reduce the delta between the mainline and the Android scheduler. Thus, whatever is related to the "low utilization mode" should be probably better defined once we are confident with this last series and based on top of it.
Hope this can cast some light in the overall design to improve the energy efficiency of prefer_idle tasks.
Of course, any contribution of ideas / testing in the above described areas are more then welcome.
Cheers Patrick
-- #include <best/regards.h>
Patrick Bellasi