content: Improve thread priority for raster threads.

base/threading/platform_thread_android.cc

Index: base/threading/platform_thread_android.cc
diff --git a/base/threading/platform_thread_android.cc b/base/threading/platform_thread_android.cc
index 1e4ae93fcf29c657af2362b2fcae75011f539a33..e6a5ef5bd44a81ea21d9aab06366d70399197f5d 100644
--- a/base/threading/platform_thread_android.cc
+++ b/base/threading/platform_thread_android.cc
@@ -24,15 +24,13 @@ namespace base {
 
 namespace internal {
 
-// - BACKGROUND is 9 due to it being the nicest value we can use that's still
-// above an Android system threshold that enables heavy throttling starting at
-// 10; we want to be lower-priority than Chrome's other threads without
-// incurring this behavior.
+// - BACKGROUND corresponds to Android's PRIORITY_BACKGROUND = 10 value and can
+// result in heavy throttling.
 // - DISPLAY is -6 due to being midway between Android's DISPLAY (-4) and
 // URGENT_DISPLAY (-8).

[reveman, 2016/02/12 05:56:44]

Seems like a bit of an abuse to take URGENT_DISPLAY that is meant for ui
services on Android into account here. -4 not enough?

[aelias_OOO_until_Jul13, 2016/02/23 23:01:40]

Yeah, it seems a bit weird.  This was introduced in
https://chromiumcodereview.appspot.com/12741012 but there's no explanation for
the choice in the patch or code review discussion.  If you want to change it to
-4, fine by me.

[reveman, 2016/02/24 17:08:53]

Created a separate patch for this: https://codereview.chromium.org/1730053003

-// - REALTIME_AUDIO corresponds to Android's THREAD_PRIORITY_AUDIO = -16 value.
+// - REALTIME_AUDIO corresponds to Android's PRIORITY_AUDIO = -16 value.
 const ThreadPriorityToNiceValuePair kThreadPriorityToNiceValueMap[4] = {
-    {ThreadPriority::BACKGROUND, 9},
+    {ThreadPriority::BACKGROUND, 10},

[reveman, 2016/02/12 05:56:44]

Note that this will also make the renderer main thread use this priority when
smoothness is preferred.

[aelias_OOO_until_Jul13, 2016/02/23 23:01:40]

Yeah, that's concerning.  I don't think we want to force the main thread onto a
little core, that seems too aggressive.  Since you're significantly changing our
thread policy anyway, could you simply delete the main-thread-priority-change
effect of smoothness preferred?  It's one of those ugly complexities in our
scheduling policy, introduced back when we had a very different rendering
architecture (I believe it was in the days when raster was on main thread, so
the effect was primarily to throttle raster) -- I question its benefit so I
think it's time to try cleaning it out.

[reveman, 2016/02/24 17:08:54]

Removed it as part of this patch.

     {ThreadPriority::NORMAL, 0},
     {ThreadPriority::DISPLAY, -6},
     {ThreadPriority::REALTIME_AUDIO, -16},