oom-kill: add lowmem usage aware oom kill handling
in [Kernel]
|
From: Vedran Furač on 28 Jan 2010 20:00 Alan Cox wrote: > On Fri, 29 Jan 2010 01:25:18 +0100 > Vedran Furač <vedran.furac(a)gmail.com> wrote: > >> Alan Cox wrote: >> >>> Am I missing something fundamental here ? >> Yes, the fact linux mm currently sucks. How else would you explain >> possibility of killing random (often root owned) processes using a 5 >> lines program started by an ordinary user? > > If you don't want to run with overcommit you turn it off. At that point > processes get memory allocations refused if they can overrun the I've started this discussion with question why overcommit isn't turned off by default. Problem is that it breaks java and some other stuff that allocates much more memory than it needs. Very quickly Committed_AS hits CommitLimit and one cannot allocate any more while there is plenty of memory still unused. > theoretical limit, but you generally need more swap (it's one of the > reasons why things like BSD historically have a '3 * memory' rule). Say I have 8GB of memory and there's always some free, why would I need swap? > So sounds to me like a problem between the keyboard and screen (coupled Unfortunately it is not. Give me ssh access to your computer (leave overcommit on) and I'll kill your X with anything running on it. -- http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12
From: Alan Cox on 29 Jan 2010 06:10 > off by default. Problem is that it breaks java and some other stuff that > allocates much more memory than it needs. Very quickly Committed_AS hits > CommitLimit and one cannot allocate any more while there is plenty of > memory still unused. So how about you go and have a complain at the people who are causing your problem, rather than the kernel. > > theoretical limit, but you generally need more swap (it's one of the > > reasons why things like BSD historically have a '3 * memory' rule). > > Say I have 8GB of memory and there's always some free, why would I need > swap? So that all the applications that allocate tons of address space and don't use it can swap when you hit that corner case, and as a result you don't need to go OOM. You should only get an OOM when you run out of memory + swap. > > So sounds to me like a problem between the keyboard and screen (coupled > > Unfortunately it is not. Give me ssh access to your computer (leave > overcommit on) and I'll kill your X with anything running on it. If you have overcommit on then you can cause stuff to get killed. Thats what the option enables. It's really very simple: overcommit off you must have enough RAM and swap to hold all allocations requested. Overcommit on - you don't need this but if you do use more than is available on the system something has to go. It's kind of like banking overcommit off is proper banking, overcommit on is modern western banking. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KAMEZAWA Hiroyuki on 29 Jan 2010 11:20 Alan Cox wrote: >> off by default. Problem is that it breaks java and some other stuff that >> allocates much more memory than it needs. Very quickly Committed_AS hits >> CommitLimit and one cannot allocate any more while there is plenty of >> memory still unused. > > So how about you go and have a complain at the people who are causing > your problem, rather than the kernel. > Alan, please allow me to talk about my concern. At first, I think all OOM-killer are bad and there are no chance to implement innocent, good OOM-Killer. The best way we can do is "never cause OOM-Kill". But we're human being, OOM-Killer can happen by _mistake_.... For example, a customer runs 1000+ process of Oracle without using HugeTLB and the total size of page table goes up to 10GByes. Hahaha. (Of course, We asked him to use Hugetlb ;) We can't ask him to use overcommit memory if much proprietaty applications runs on it.) So, I believe there is a cirtial situation OOM-Killer has to run even if it's bad. Even in corner case. Now, in OOM situaion, sshd or X-server or some task launcher is killed at first if oom_adj is not tweaked. IIUC, OOM-Killer is for giving a chance to administrator to recover his system, safe reboot. But if sshd/X is kiiled, this is no help. My first purpose was to prevent killing some daemons or task launchers. The first patch was nacked ;). On that way, I tried to add lowmem counting because it was also my concern. This was nacked ;( I stop this because of my personal reason. For my enviroment, panic_on_oom=1 works enough well.For Vedran's, overcommit memory will work well. But oom-killer kills very bad process if not tweaked. So, I think some improvement should be done. And we have memcg even if it's called as ugly workaround. Sorry for all the noise. Bye, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KAMEZAWA Hiroyuki on 29 Jan 2010 11:30 Alan Cox wrote: >> panic_on_oom=1 works enough well.For Vedran's, overcommit memory will >> work >> well. But oom-killer kills very bad process if not tweaked. >> So, I think some improvement should be done. > > That is why we have the per process oom_adj values - because for nearly > fifteen years someone comes along and says "actually in my environment > the right choice is ..." > > Ultimately it is policy. The kernel simply can't read minds. > If so, all heuristics other than vm_size should be purged, I think. ....Or victim should be just determined by the class of application user sets. oom_adj other than OOM_DISABLE, searching victim process by black magic are all garbage. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 29 Jan 2010 11:30
> panic_on_oom=1 works enough well.For Vedran's, overcommit memory will work > well. But oom-killer kills very bad process if not tweaked. > So, I think some improvement should be done. That is why we have the per process oom_adj values - because for nearly fifteen years someone comes along and says "actually in my environment the right choice is ..." Ultimately it is policy. The kernel simply can't read minds. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |