Comment 5 for bug 1478853

There's not enough information here to make a proper attack on this issue, and this is a complex topic.

We need someone to sit down and determine things like:
1. why did the OOM killer strike a foreground app? Did it use an insane amount of memory? If a webapp, is it a QtWebkit-based app, or Oxide? Does Oxide cache much in memory?
2. would more graded OOM scoring really make an impact. How much does the OOM killer take this score into account. Maybe the scores being currently set are not strong enough.
3. Is the OOM killer cgroup aware? Can we be sure it won't kill any process in a cgroup that is containing the app currently focused by the user
4. is the default kernel OOM killer really the right thing to rely on for a phone? I believe it tries to prioritize killing memory-greedy apps over longer-running ones, i.e. if your app starts eating lots of memory, it'll kill it first. I don't think Android uses it
5. has anyone profiled these apps to see if easy memory savings could be made? Are they loading large high-res graphics?
6. has anyone profiled unity8/maliit/dash and all the system services to try reduce their memory usage?