diff options
| author | Joel Fernandes <joelaf@google.com> | 2017-04-04 16:32:15 -0700 |
|---|---|---|
| committer | Joel Fernandes <joelaf@google.com> | 2017-04-05 20:25:43 -0700 |
| commit | 474d311cb098e86c078c3f615e1161e2854f1847 (patch) | |
| tree | 53c53a24e076a245425be4fcb17d8f9e8dbbdcee /rs/java/android/renderscript/ProgramFragmentFixedFunction.java | |
| parent | 55ef06b2f481731c98891138d1d18f91c281db6d (diff) | |
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>
Diffstat (limited to 'rs/java/android/renderscript/ProgramFragmentFixedFunction.java')
0 files changed, 0 insertions, 0 deletions