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)

1 files changed, 4 insertions, 0 deletions

diff --git a/services/java/com/android/server/SystemServer.java b/services/java/com/android/server/SystemServer.java
index 63af2da93a86..f74512a00122 100644
--- a/services/java/com/android/server/SystemServer.java
+++ b/services/java/com/android/server/SystemServer.java
@@ -614,6 +614,10 @@ public final class SystemServer {
         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));