Hello EAS-dev!

ARM is pleased to announce the EAS r1.3 release.

This is the next tick in our regular updates to EAS in AOSP, including documentation and testing updates. In particular this release is the first major update to EAS in Android Common Kernel 4.9

Changes in EAS 1.3 * Validation on real devices and additional development boards (Hikey960) * Increased test coverage * Upstream schedutil backporting * Schedutil is now the recommended CPUFreq governor * General EAS refactoring improvements (find_best_target changes) * android common kernel-4.9 brought to EAS equivalence with 4.4

Android Common Kernel 4.4: https://android.googlesource.com/kernel/common/+/android-4.4

Android Common Kernel 4.9: https://android-review.googlesource.com/#/c/444387/ Once merged into android-4.9, the gerrit web interface will tell you that the patches have been merged however the changeset link should stay active.

Documentation: https://developer.arm.com/-/media/developer/developers/open-source/energy-aw...

Specifically about schedutil: We have backported schedutil patches up until 38d4ea229d which was included in v4.12. (https://github.com/torvalds/linux/commit/38d4ea229d25d30be6bf41bcd6cd663a587...) "cpufreq: schedutil: Trace frequency only if it has changed".

The version included in android-4.9 includes backported patches to the same level. This brings schedutil in both versions of Android up to v4.12.

We have satisfied ourselves in testing that this version of schedutil works well enough to be used in place of schedfreq both for performance and energy usage.

EAS Updates: We have done a large refactoring of find_best_target as it was beginning to become difficult to make further improvements without impacting other behaviors. The refactored version has exactly the same behaviour in the refactor commit, and it has allowed us to further refine the task of selecting a CPU during wakeup. We added the ability to return a second target CPU from find_best_target, which is chosen using a different strategy. When the first target is not allowable due to the energy/performance trade-off not being good enough, we now check the alternative strategy as well (but only if the primary strategy fails).

A new tracepoint was added to help in understanding EAS task placement decisions - sched_find_best_target - which traces the task, schedtune flags and CPUs which were selected by find_best_target for energy evaluation.

More patches were added to improve system behavior with idle CPUs. We now prevent an idle CPU from holding the system in overutilized mode (if it was overutilized just before going into nohz mode), allowing EAS to handle task placements again sooner. In addition, when misfit tasks are present, we bypass some of the normal nohz balance rate-limiting to reduce the time needed for those tasks to be redistributed.

Finally, we added the ability for EAS to forecast the idle state which could potentially be selected under the utilization conditions when calculating the energy for a particular sched group. The forecast is intentionally simple as it is done during wakeup - we reserve the deepest idle state for completely idle groups and otherwise linearly map the group utilization to idle states. In previous versions, EAS used the current idle state when estimating energy. This change allows EAS to see the potential impact of moving the last task from one group to another and move tasks if appropriate.

Android-4.9: android-4.9 has not yet had the same level of testing that android-4.4 has due to us having a limited set of platforms which can run a 4.9 kernel version. For most of this dev cycle we have only had access to Juno, and we have confirmed that our tests behave the same on 4.9 as they do on 4.4. In the last week or two, the Hikey960 board has gained a usable BSP for running android-4.9, so we have also been testing that but it is too early to share those results.

We continue to develop EAS on AOSP in public. Please feel free to participate in testing patches, reviewing code and generally being a good open-source citizen.

Best Regards, Chris Redpath