[Suggestion] Allow for overkill to make restoring easier

[konstantinua00]

I'm a browser tab hoarder, so I get into high RAM use situations often, thus I have been using earlyoom for quite some time. I have setup the --avoid and --prefer options to target web pages and leave some most used applications alone. Generally, the experience is as follows: I open apps and browser -> I use both switching from one to another -> I open too many tabs and cause RAM usage go over the threshold -> browser says that tab crashed, most likely due to memory shortage, and proposes to restore it

Problem: most of the time when I restore the tab... it gets chosen to be killed again. I don't know why, but it seems that active tab - even without any actions done on it and it not having finished loading - gets more memory given to it than to used - but "used some time ago" - tabs. To get around this I usually go to system monitor and manually kill several more tab processes (and they're easy to find, being high on the memory usage list)

So... I came here to propose to automate such solution. Either

• make earlyoom kill several processes at the memory lack event (via option) That way multiple tabs would be closed and opening one wouldn't get it closed straight away

or, which is different, but might be more useful for others:

• create second threshold - one, until achieving which, killing will not stop This way system and/or user will have breathing space after the oom trigger without oom killing everything that gets newly created

[mikkorantalainen]

The correct way to fix this would be Chrome not volunteering the active tab equally high as the background tabs. The problem is caused Chrome blindly setting oom_score_adj to 300 for all renderer processes. If they set oob_score_adj to e.g. 200 for the foreground tab (or didn't mess with the value at all), you wouldn't have similar issues.

Are you seeing this problem with any browser that doesn't use the Blink rendering engine (e.g. Chrome, Opera, Brave, Vivaldi)?

[rfjakob]

What you call overkill could be called hysteresis, and I think this can make sense

[joeytwiddle]

My theory for this was that the active tab really does consume more memory than inactive tabs, due to the activity of parsing the page and running JavaScript, before garbage reclaim later reduces its footprint.

My solution/mitigation was to slightly prefer to kill older processes. That half worked. Sometimes the first reload would load the page using an already existing chrome process, and it would quickly get killed again. But usually (not always) the second reload would stay alive. (Either because chrome had started a new process for it, or because overkill had happened unintentionally.)

An optional to do a little overkill/hysteresis would probably work quite well. :+1: