On Mon, Mar 5, 2012 at 10:04 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 05 Mar 2012 21:58:26 +0200 > Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > >> Hi all, > >> I assumed that when setting overcommit_memory=2 and >> overcommit_ratio<100 that the OOM killer won't ever get invoked (since >> we're not overcommiting memory), but it looks like I'm mistaken since >> apparently a simple mmap from userspace will trigger the OOM killer if >> it requests more memory than available. >> >> Is it how it's supposed to work? Why does it resort to OOM killing >> instead of just failing the allocation? >> >> Here is the dump I get when the OOM kicks in: >> >> ... >> >> [ 3108.730350] [<ffffffff81198e4a>] mlock_vma_pages_range+0x9a/0xa0 >> [ 3108.734486] [<ffffffff8119b75b>] mmap_region+0x28b/0x510 >> ... > > The vma is mlocked for some reason - presumably the app is using > mlockall() or mlock()? So the kernel is trying to instantiate all the > pages at mmap() time. The app may have used mlock(), but there is no swap space on the machine (it's also a KVM guest), so it should matter, no? Regardless, why doesn't it result in mmap() failing quietly, instead of kicking in the OOM killer to kill the entire process? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href