Wrong Android OOM order when Chrome is backgrounded |
||
Issue descriptionVersion: 52.0.2742.0 OS: Android (tested on a jellybean phone and a kitkat tablet). What steps will reproduce the problem? (1) Open chrome (2) Run "adb shell dumpsys activity". "sandboxed_process0" should be there (3) Create a new tab (4) Run "adb shell dumpsys activity". "sandboxed_process1" should be above "sandboxed_process0". "sandboxed_process1" (and sandboxed_porcess0 should be "vis", indicating a moderate binding) (5) Tap the Android home button to go the launcher (6) Run "adb shell dumpsys activity". Notice that "sandboxed_process1" is *below* "sandboxed_process0" (7) Wait 10 seconds (8) Run "adb shell dumpsys activity". Notice that "sandboxed_process1" is now above "sandboxed_process0" again Similar flow: (1) Open chrome (2) Run "adb shell dumpsys activity". "sandboxed_process0" should be there (3) Create a new tab (4) Run "adb shell dumpsys activity". "sandboxed_process1" should be above "sandboxed_process0". "sandboxed_process1" (and sandboxed_porcess0 should be "vis", indicating a moderate binding) (5) Tap the Android home button to go the launcher, open an unrelated app, tap home button again (do this all quickly) (6) Run "adb shell dumpsys activity". Notice that "sandboxed_process1" is below "sandboxed_process0" again. Note that this doesn't correct after 10 seconds. What is the expected output? In both flows, step 6 should still have "sandboxed_process1" above "sandboxed_process0" What do you see instead? In both flows, step 6 has "sandboxed_process0" above "sandboxed_process1"
,
May 25 2016
Oh this was the thread Alexandre pointed to previously: https://groups.google.com/a/google.com/forum/#!msg/chrome-ads-team/Kpe4thJCsm0/ghYo9vOvCAAJ Based on meatspace discussion, perhaps this is as expected. If the problem is that chrome gets into the background bucket, then having a strong binding isn't going to help us as it won't elevate out of that. Still the fact that sandboxed_process0 is above sandboxed_process1 is surprising.
,
May 25 2016
Yeah, my understanding is that binding strength determines what bucket we're in, but if multiple processes end up in the same bucket regardless, the secondary ordering depends on on accidental implicit factors that influence the binding tree walk order. I don't know the exact tree walk algorithm and wasn't aware of this particular problem. If we could develop a full understanding of it, it might be manipulatable with a trick along the lines of creating or touching the bindings in the right order.
,
Jun 3 2016
Looks like the selection process for which process to kill is not just LRU. It's described here: https://www.kernel.org/doc/gorman/html/understand/understand016.html I've corroborated this with some local tests, so closing as WAI. |
||
►
Sign in to add a comment |
||
Comment 1 by yfried...@chromium.org
, May 25 2016