oom-kill: add lowmem usage aware oom kill handling
in [Kernel]
|
From: Vedran Furač on 30 Jan 2010 07:50 David Rientjes wrote: > The oom killer has been doing this for years and I haven't noticed a huge > surge in complaints about it killing X specifically because of that code > in oom_kill_process(). Well you said it yourself, you won't see a surge because "oom killer has been doing this *for years*". So you'll have a more/less constant number of complains over the years. Just google for: linux, random, kill, memory; What provoked me to start this discussions is that every few months on our croatian linux newsgroup someone starts asking why is linux randomly killing his processes. And at the end of discussion a few, mostly aix/solaris sysadmins, conclude that linux is still a toy. Regards, Vedran -- http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12
From: Alan Cox on 30 Jan 2010 08:00 > > So how about you go and have a complain at the people who are causing > > your problem, rather than the kernel. > > That would pass completely unnoticed and ignored as long as overcommit > is enabled by default. Defaults are set by the distributions. So you are still complaining to the wrong people. > So, if you don't want to change the OOM algorithm why not fixing this > bug then? And after that change the proc(5) manpage entry for > /proc/sys/vm/overcommit_memory into something like: > > 0: heuristic overcommit (enable this if you have memory problems with > some buggy software) > 1: always overcommit, never check > 2: always check, never overcommit (this is the default) Because there are a lot of systems where heuristic overcommit makes sense ? 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: Vedran Furač on 30 Jan 2010 12:40 Alan Cox wrote: >>> So how about you go and have a complain at the people who are causing >>> your problem, rather than the kernel. >> That would pass completely unnoticed and ignored as long as overcommit >> is enabled by default. > > Defaults are set by the distributions. So you are still complaining to > the wrong people. I can't say I'm able to correctly read kernel code, but I believe default is set by: int sysctl_overcommit_memory = OVERCOMMIT_GUESS; /* heuristic overcommit */ int sysctl_overcommit_ratio = 50; /* default is 50% */ int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT; in mmap.c. >> So, if you don't want to change the OOM algorithm why not fixing this >> bug then? And after that change the proc(5) manpage entry for >> /proc/sys/vm/overcommit_memory into something like: >> >> 0: heuristic overcommit (enable this if you have memory problems with >> some buggy software) >> 1: always overcommit, never check >> 2: always check, never overcommit (this is the default) > > Because there are a lot of systems where heuristic overcommit makes > sense ? Ok, I won't argue any more. Just please watch this short (~1min) screencast I made and tell me which behavior is good and which is bad and should be fixed: http://vedranf.net/tmp/oom.ogv (you can watch it using VLC for example) Actually anyone receiving this mail should see it. What do you think, what will customers rather choose if they see this? Regards, Vedran -- http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12
From: Vedran Furač on 30 Jan 2010 13:20 Alan Cox wrote: >> http://vedranf.net/tmp/oom.ogv (you can watch it using VLC for example) >> >> Actually anyone receiving this mail should see it. What do you think, >> what will customers rather choose if they see this? > > Address that to the distributions. Their customers. Systems I set up for > people always have no overcommit enabled. And distros say that's a bug in kernel. Result: nothing gets done and users will continue to swear at linux after it kills their work... -- http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12
From: David Rientjes on 30 Jan 2010 18:00
On Sat, 30 Jan 2010, Vedran Furac wrote: > > The oom killer has been doing this for years and I haven't noticed a huge > > surge in complaints about it killing X specifically because of that code > > in oom_kill_process(). > > Well you said it yourself, you won't see a surge because "oom killer has > been doing this *for years*". So you'll have a more/less constant number > of complains over the years. Just google for: linux, random, kill, memory; > You snipped the code segment where I demonstrated that the selected task for oom kill is not necessarily the one chosen to die: if there is a child with disjoint memory that is killable, it will be selected instead. If Xorg or sshd is being chosen for kill, then you should investigate why that is, but there is nothing random about how the oom killer chooses tasks to kill. The facts that you're completely ignoring are that changing the heuristic baseline to rss is not going to prevent Xorg or sshd from being selected (in fact, I even showed that it makes Xorg _more_ preferrable when I reviewed the patch), and you have complete power of disabling oom killing for selected tasks and that trait is inheritable to children. I agree that we can do a better job than needlessly killing innocent tasks when we have a lowmem oom. I suggested killing current in such a scenario since ZONE_DMA memory was not reclaimable (and, soon, not migratable) and all memory is pinned for such purposes. However, saying we need to change the baseline for that particular case and completely misinterpret the oom_adj values for all system-wide tasks is simply not an option. And when that point is raised, it doesn't help for people to take their ball and go home if their motivation is to improve the oom killer. -- 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/ |