- Ideally we should never hit the OOM killer, but we do, because of bugs, design issues (we don't discard visible tabs), and performance issues (can't discard quickly enough)

- When tabs are discarded or OOM-killed, there is a concrete risk that we throw away state that is useful to the user.  This will remain true for a while at best.

- We try hard to guess which tabs are the least useful.  Once we have made that guess, it seems logical that we would like the OOM killer to try to follow the same choice.

Maybe you're saying that if we need 100MB and the LRU tab is only 50MB and the next one is 200MB we might as well OOM-kill the latter first, instead of both.  That may be true, but then the tab discarder should follow the same logic as well.

> When tabs are discarded or OOM-killed, there is a concrete risk that we throw
> away state that is useful to the user.  This will remain true for a while 
> at best.

Yup.  I'm not saying it's good to throw the ice chest overboard (it's got all our food and drinks), but it's better than crashing into the tree.  ...but I'm saying that we should have thought of that before the tree was in front of us.  :-P

---

> We try hard to guess which tabs are the least useful.  Once we have made that
> guess, it seems logical that we would like the OOM killer to try to follow 
> the same choice.

I'd be OK with some amount of tendency towards killing less useful stuff, but there needs to be a _much_ bigger emphasis on how much memory is used than there is today.


A) I guess one option is to try to make userspace account for "amount of memory" a little bit more, but as per above, I think "amount of memory" isn't as useful of a metric when we're not desperate.  AKA as long as we're not acting out of desperation then I'm OK ignoring "memory used" and relying solely on "usefulness".  

B) Another option is to have userspace keep assigning an OOM score but compress the OOM scores a bit.  AKA instead of assigning scores between 300 and 600, assign scores between 300 and 310, or something like that (someone would need to do the math to see exactly what the range should be).  This provides information to the kernel about usefulness but doesn't fully override it's "heavy hammer" approach.

---

> Maybe you're saying that if we need 100MB and the LRU tab is only 
> 50MB and the next one is 200MB we might as well OOM-kill the latter first, 
> instead of both.  That may be true, but then the tab discarder should 
> follow the same logic as well.

It's more like if we need 100 MB and we pick a background android process worth 5 MB then that wasn't too useful.  If freeing 5 MB would have been enough then we (presumably) wouldn't be in the "oh crap" OOM kill situation--userspace would have taken care of things.  The fact that we're in OOM kill means our normal mitigations failed.

We avoided the 5 MB issue with the hack that's in  bug #728865 , but that gets us into the next situation.  Now imagine we've got an background Android process that's 500 MB.  We'd rather kill that.  AKA: memory used is the important thing for the OOM killer.

---

Basically I'm arguing that we shouldn't focus on trying to pick the exactly right thing in OOM kill.  We should be focusing on picking the best "big thing".  Then we should keep focusing on avoiding the OOM killer wherever possible.

We have work in-progress to do a better job of proactively discarding tabs, and hopefully we can find resources to apply that similarly to ARC processes.

We're always going to have a risk of hitting kernel OOMs, though, so setting OOM score adjustments makes sense, but not with the fine-grained scores we're setting right now.  It should be straightforward to group processes into a small set of OOM-score-adj bands, so that the kernel can pick the biggest process from the "least needed" band if/when we do hit OOM.

If we use coarse-grained bands, based on each process' state (i.e. focused, active, important) then we also don't need to calculate an ordering - we can set the individual process' OOM-score-adj directly as soon as its state changes, moving it between the different buckets, for example.

I agree with the basic logic that on emergency situation, we should allow a little out-of-order OOM killing so the system has a better chance to get back to normal. I'll check kernel OOM formula for setting proper values for each bucket.

Since the original problem seems to be caused by a bunch of "focused tabs" with OOM score 300. Moving them back to "background tabs buckets" as soon as possible would be a vital step. 

This bug has an owner, thus, it's been triaged. Changing status to "assigned".