+folks who might be interested.

limiting CPU usage is a pretty big hammer. not sure if everything that uses TaskPriority::BACKGROUND is really ready for that kind of restriction.

I found at least one that's clearly wrong:
https://cs.chromium.org/chromium/src/content/renderer/gpu/render_widget_compositor.cc?rcl=fa6b5750d1651fdf1e135212bf5237ad689beba6&l=330

So not against it, but probably should proceed carefully

Yeah, I don't really have anything to add beyond what Bo says here - this is much more intrusive than what BACKGROUND implies on other platforms, so some of the usages might not be appropriate, but it seems like in general this could be desirable for the overall scheduling benefit to the device.

Aha, I see boliu@ fixed RenderWidgetCompositor::CreateLayerTreeHost() to use USER_VISIBLE priority. I guess I'll prepare the CL, and we'll see.

I have a CL here: https://chromium-review.googlesource.com/c/chromium/src/+/868576

It has a downside though - it changes place where android::AttachCurrentThread() is called - it's now called when setting a priority, not when retrieving it. I would assume that setting priority is more common than retrieving it, but I'm not sure.

I feel android::AttachCurrentThread() should have memory impact and I would like to avoid it. But avoiding it means complicating the implementation - basically we'll need a dedicated thread for setting priorities in case current thread doesn't have JNIEnv attached.

What do you folks think? Do we need to bother?

I suspect we already attach most of our threads to the VM at some point in their lifetime. In fact, we should probably be doing this *more*, so that we can give them JVM-visible names for thread dump purposes (I think there's a bug open about this somewhere).

It's probably not a big deal.

Regarding the background cgroup, this is something we should probably look at more closely. For instance, all AsyncTasks are typically runnable on a single little core for most user devices, which is probably not what we want at times (library loading, for instance).

Can we introduce a new priority ThreadPriority::THROTTLED and map the cgroup changing call to that one instead?

BTW, ChromeOS already assigns BACKGROUND threads to little cores. See base/threading/platform_thread_linux.cc where BG threads are assigned to "non-urgent" cgroup and https://www.chromium.org/chromium-os/chromiumos-design-docs/chromium-os-cgroups for a brief description of what "non-urgent" means. Also see https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/383992 for a sample platform-cpusets.conf.

But ChromeOS probably has PTHREAD_PRIO_INHERIT, which Android lacks (b/29177606). So I wonder if landing the CL will make us vulnerable to priority inversion.

Would it be possible to add a DEBUG-mode check that UI threads never block on background threads? Even if we had PTHREAD_PRIO_INHERIT, I don't think we'd want UI thread blocking.

Some discussion about this in  bug 618424 . Particularly - points out that there's a background raster thread that would need to use "non-urgent" rather than background as well.

Discovered similar  issue 618424 .

Available, but no owner or component? Please find a component, as no one will ever find this without one.