Messages in this thread | | | Date | Mon, 5 Mar 2012 12:04:27 -0800 | From | Andrew Morton <> | Subject | Re: OOM killer even when not overcommiting |
| |
On Mon, 05 Mar 2012 21:58:26 +0200 Sasha Levin <levinsasha928@gmail.com> 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.
| |