Comment 12 for bug 1542002

I did an experiment: I commented out the code that unloads background tabs in the browser, and opened a large number of tabs with memory-hungry websites (google maps, here maps, google docs, youtube, google plus, …).

The OOM killer eventually kicked in, but it didn’t kill oxide renderer processes, instead it killed the browser process directly (before that it had killed a number of background apps):

Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] (0)[54:kswapd0]lowmemorykiller: Killing 'webbrowser-app' (7243), adj 1, score_adj 110,
Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] to free 524140kB on behalf of 'kswapd0' (54) because
Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] cache 65320kB is below limit 65536kB for oom_score_adj 12
Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] Free memory is 0kB above reserved

I wonder if the OOM killer logic could be tuned to kill renderer processes first, and then the browser process as a last resort.

Note that the initial report said that the browser crashed, but it’s incorrect: the browser is being killed, which makes it instantly disappear, thus appearing to be a crash to the user, but there’s no crash file, the process was simply terminated by the system.

As for the major slowdown, not really sure what can be done about it: when out of memory, the system is bound to be slower. Note that the new browser mechanism to unload background tabs when low on memory should mitigate the issue.