Need to lower the priority of the TDI renderer process |
|||
Issue descriptionTopDocumentIsolation feature (tracked by issue 595987) can put some cross-site subframes into a separate renderer process (to isolate performance of the top document from the performance of the frames put into the TDI process). Ideally, the TDI renderer process should: 1) run with a lower priority from the main content renderer 2) be the first candidate for being killed when we are low on resources (memory or otherwise). Note that the above is true even if the TDI content is being rendered in a foreground tab (we want to sacrifice the TDI process to help improve performance and OOM rates of the main content). Let's use this bug for figuring out how to tell the rest of Chrome that the TDI renderer should be treated as low priority.
,
Jun 14 2017
,
Jun 15 2017
Maybe the TDI process should be "backgrounded" by RenderProcessHostImpl::UpdateProcessPriority? - AFAIR Chrome applies some pretty aggressive interventions to background processes (i.e. throttling granularity of javascript timers), so I am not sure if a "background" priority is the right priority for the TDI process. - An extra difficulty is that TDI process hosts content from multiple tabs (some of them visible and some not). Right now |should_background| in RenderProcessHostImpl::UpdateProcessPriority looks if |visible_widgets_| is 0 - such process-wide policy might me inappropriate in case of the TDI process.
,
Jun 16 2017
My 2c is that we need to run the TDI process in normal priority. The reason is that the content of at least one frame in that process will be visible to the user and should be responsive. We get the performance separation already by splitting the main frame from the subframe across processes, so I don't think it is necessary to go further and decrease the OS level priority of the process. Being the first to be killed on low resources is definitely a good thing though and should be our policy.
,
Jun 16 2017
+1. The only thing we should change for initial release is the Android bindings so the OOM killer kills the TDI process first. We might learn things after the first release about other priority stuff we might want to do, but I suspect it will be subtle and complicated.
,
May 8 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by lukasza@chromium.org
, Jun 14 2017Cc: agrieve@chromium.org