Stability and Memory Pressure in 8.2

[Deepak Saxena]

>   * We need to find out why the oom-killer is not killing things fast
>     enough. Based on our results, we might consider configuring
>     /proc/$pid/oom_adj to preferentially kill some processes (e.g., the
>     foreground [or background?] activities.)

In the cases I've been playing with, browse is the only activity that
is running. Will try bumping its oom_adj to see if this improves OOM
kill latency.

>   * We need to determine whether the oom-killer is killing the right
>     processes. (sysctl's vm.oom_dump_tasks can be set to 1 in order to
>     get more verbosity from the oom-killer when it fires).

>From watching top, it appears that we're killing the correct process. For 
example, when running the test case from #8316, OOM killer does not kill 
browse, but just kills the gnash instance which is chewing up RAM.

>     - the warnings in the ramfs and tmpfs code about the deadlocks that
>       tmpfsen can generate under low- or no-memory conditions.

I have yet to see an actual deadlock. What I saw when trying to
reproduce #3816 is that the OOM killer just takes a very very long
time to kick in.

>     - whether our kernel "overcommits" when allocation requests are made?

By default vm.overcommit_memory is set to 0 which will refuse "Obvious
overcommits of address space". I will try setting this to 3 along with
vm.overcommit_ratio to 0 to force no overcommit at all and see how the 
system reacts.

~Deepak