OOM killer score calculations should be improved

[Michael Zanetti]

There are a couple of issues with the current way of calculating the OOM score. It happens that the two frequently used apps are killed repeatedly, while there are many other apps sitting in the right edge not being killed. This also manifests in issues like bug 1421241.

I think the OOM score calculation should take recency of use into account instead of only looking at memory usage of an app. The memory usage might still be taken into account as it could indeed make sense to kill one large app instead of 5 small ones, but not if that one large app is the one that the user keeps on switching to.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ted Gould (ted)]

Agree that this would be a good feature, along with others, if we were to write our own OOM killer algorithm. For reference, here is the code in the kernel:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/mm/oom_kill.c#n155
(I think we're also using the lowmemory driver from Android, but it's roughly the same with earlier penalties)

I think it should take into account LRU, but then also the processes in the cgroup as for us we know that a cgroup represents an application. Killing one process in an application is kinda silly. There has be some discussion of doing this in userspace at the low memory levels which we could definitely do, then let the kernel be stupid and quick in emergencies, but that currently isn't on the list of things that UAL does (and I think it should be a different project) so marking invalid for UAL.

[Gerry Boland (gerboland)]

@ted, you're not wrong, the default kernel OOM killer isn't ideal for us. But writing a new one is a lot of work, especially as we have several different kernel releases to deal with.

What would be less ideal, but most likely good enough to fix most user-visible bugs in the short term, is to allow shell (which is aware of the connection between apps and prompt providers) to set OOM scores itself.

Shell can then use that to influence the kernel to not kill the app the user is most likely going to return to. It would also help prevent recently-used apps from being killed before older ones.

To achieve that will require changes to UAL, so I'm reopening.

[Ted Gould (ted)]

I'm going to go ahead and mark this as a duplicate of bug 1579799, what I think is important is mentioned there; we need to enumerate the states that we want applications in. I don't think putting magic numbers in the shell makes sense.