Set android.display thread to top-app cpusets and schedtune group
android.display being in the foreground cpuset group is an issue. As
seen on M/S, during heavily CPU load it is not given core 3 even though
it might be free and causes jank. This patch adds the thread to the
top-app group to ensure it is placed on all cores during scheduling
decisions.
Doing this required a couple of changes:
- new API to set per-thread cpusets
- changes to DisplayManagerService to set the thread to top-app group
- changes to SystemServer to set the policy toward the end, as doing it
during start of the DisplayManagerService was in issue (issue being
SystemServer calls setSystemProcess.. -> setProcessGroup which overrides
the group settings for threads in the system server process, including
android.display)
Bug: 36631902
Test: Boot and make sure android.display thread is in the top-app group
Change-Id: Icc394ea0ffcf159d11728ad38de114234a29d20f
Signed-off-by: Joel Fernandes <joelaf@google.com>
(cherry picked from commit 474d311cb098e86c078c3f615e1161e2854f1847)
diff --git a/services/java/com/android/server/SystemServer.java b/services/java/com/android/server/SystemServer.java
index 63af2da..f74512a 100644
--- a/services/java/com/android/server/SystemServer.java
+++ b/services/java/com/android/server/SystemServer.java
@@ -614,6 +614,10 @@
mActivityManagerService.setSystemProcess();
traceEnd();
+ // DisplayManagerService needs to setup android.display scheduling related policies
+ // since setSystemProcess() would have overridden policies due to setProcessGroup
+ mDisplayManagerService.setupSchedulerPolicies();
+
// Manages Overlay packages
traceBeginAndSlog("StartOverlayManagerService");
mSystemServiceManager.startService(new OverlayManagerService(mSystemContext, installer));