On Wed, Jan 27, 2010 at 7:53 PM, Denis Doroshenko <denis.doroshe...@gmail.com> wrote: > On 1/28/10, nixlists <nixmli...@gmail.com> wrote: >> Why kill random processes that may not be misbehaving and/or cause a >> kernel panic when you want to kill the process(es) that leak memory or >> are hungry in the first place? It's possible to avoid kernel panics in >> this case IMO, and not kill random processes. > > aren't you missing the point of original comment made by Otto? > > consider a situation, when all the processes in the system "are > behaving", none of them violates their rlimits, but they all together > have allocated more memory than the box contains (RAM + swap).
The idea is to limit memory such that running out of RAM+swap is not possible, or unlikely. You can set the limit on the allowed number of processes as well. You know how much memory you have, you know how much memory to give to your processes. You can set limits. IOW, you should tell the system which processes to kill when they use too much, and how many processes to run - not let the system reach the OOM state and start killing random processes (and I think this is stupid) or panic. > so the OS needs to do something. what should it do? should it just > panic? or may be losing one process is better than losing them all? > then, what are the criteria for choosing processes to be killed?.. Again, the configuration should be such that reaching the OOM state is unlikely. If after all, this state is reached, I think letting the kernel going berserk and kill random processes isn't helping much. > wondering if "random" means the process with PID 1 could be one of them...
