Ilja - can you take this?

A workaround is to manually switch tabs back and forth to trigger cgroup assignment: https://chromium-review.googlesource.com/338044

Note this seems to be a telemetry problem (or chrome remote debugging protocol problem). Running graphics_WebGLAquarium is just a convenient way to reproduce this problem, and foreground renderer process not being assigned to the correct cgroup probably does not affect the result of graphics_WebGLAquarium (at least for now).

Actually I think this is not a telemetry issue. The issue is in chrome itself. See  issue 537671  and  issue 601184 . A similar issue has reported on Android, and I can confirm that if we explicitly trigger UpdateProcessPriority() on renderer process creation for OS_CHROMEOS, then the renderer process' cgroup is correctly assigned.

Disabling toggling of UpdateProcessPriority() on renderer startup was an intentional change ( http://crbug.com/560446  -- it resulted in incorrectly backgrounding foreground renderers until navigation completed and a widget was finally made visible in the content).

We need to find a better way to know whether a renderer is working towards visible content then "number of visible widgets" as that's zero until navigation commit...

Maybe CrOS does things differently and UpdateProcessPriority() should be kept enabled for it but on desktop we ran an experiment (tracked in issue 579116) which concluded that forgo'ing the initial UpdateProcessPriority() resulted in faster PLT (essentially err'ing towards incorrectly foregrounding background tabs until they are explicitly switch to and away from instead of incorrectly backgrounding foreground navigations).

Some background on CrOS: On CrOS, the "priority" of the renderer process is controlled by assigning the process to the chrome_renderer/foreground or chrome_renderer/background cpu cgroup. The cpu bandwidth is divided between the foreground and background renderers approximately 100 to 1. As far as priority is concerned, I think not triggering UpdateProcessPriority() at process creation is probably okay: a new renderer process belongs to neither foreground nor background cpu cgroup, so it will get equal share of cpu bandwidth as all other processes in the system.

I'm experimenting with renderer process boosting on heterogeneous multiprocessor (HMP) platform (e.g. ARM big.LITTLE architecture) through cgroup, and right now when you create a new foreground tab on CrOS its corresponding renderer process is not set to any cgroup (which works as intended). I need the new foreground renderer process to be in the foreground cgroup because I use the foreground cgroup to control task placement and/or cpu frequency selection. This is a feature that we may want to ship to improve CrOS performance on HMP system.

"when you create a new foreground tab on CrOS its corresponding renderer process is not set to any cgroup (which works as intended)"

Why is this WAI? Isn't this the side-effect of not calling UpdateProcessPriority() on renderer startup? Wouldn't we want that renderer to explicitly be placed in the foreground cgroup?

Sounds like we need a cross-platform solution to this problem. RenderProcessHostImpl doesn't have enough information right now to make the right decision at renderer process creation time (until navigation commit) but it needs to.

Oh, I said WAI because we disabled UpdateProcessPriority() currently. Ideally it's just like what you said, we need a good way to make precise decision on renderer process creation time.

I uploaded https://codereview.chromium.org/1894043002/ to call UpdateProcessPriority() on renderer startup for Chrome OS in the hope that it'll put new foreground tabs into the foreground cgroup. Is there a better way to do this?

If we re-enable it then it's very possible that CrOS will be susceptible to  issue 560446  (just like Android may be, ref.  issue 601184 ) -- i.e. foreground tab will eventually end up in foreground cgroup but may be in background cgroup until navigation commits...

If a cgroup is required than I guess that's better than nothing but otherwise I'm leery of patching it per your CL.

WDYT?

PS: chrisha/georgesak are currently designing a priority-manager for tabs/processes that will have a lot more context than RenderProcessHostImpl currently does and could make better decisions here.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+boliu/oysteine: with recent work for  issue 560446  /  issue 537671 , do you think CrOS is unblocked to use the same mechanism and re-enable its UpdateProcessPriority()?

 issue 537671  is using whether there's a pending view as an additional signal (on android only, my change).  Issue 560446  is "global resource manager", which is much more bigger project that oysteine is working on. They are not all that related..

pending view is not good enough to solve the original problem reported in  issue 560446 , which is that when a new tab is that page load while tab is in the background takes a long time. A web_contents does not need to create any pending views for its first navigation; plus I imagine page commit is too early to drop priority.

So feels like desktop needs a "page loading" signal instead. I'm not sure if one is readily available. I think it should be fine for android to such a signal instead of using pending views as well.

I don't work on much on desktop though. Someone else probably want to take this instead..?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot