Messages in this thread | | | Subject | Re: [PATCH] fix spurious OOM kills | From | Thomas Gleixner <> | Date | Wed, 24 Nov 2004 17:36:52 +0100 |
| |
On Wed, 2004-11-24 at 16:52 +0100, Martin MOKREJŠ wrote: > > No, it's not related to hyperthreading. It's on the way out. > > > > I put an additional check into the page allocator. Does this help ? > > The application got killed. But, consider yourself the stacktrace ... ;)
> oom-killer: gfp_mask=0x1d2 > Free pages: 3932kB (112kB HighMem) > [<c0103dfd>] dump_stack+0x1e/0x22 > [<c013ec1c>] out_of_memory+0x97/0xcf > [<c0146dc8>] try_to_free_pages+0x163/0x184 > [<c013fde2>] __alloc_pages+0x27e/0x400 > [<c0142368>] do_page_cache_readahead+0x15b/0x1b9 > [<c013c5aa>] filemap_nopage+0x2d4/0x375 > [<c014aa82>] do_no_page+0xc4/0x38c > [<c014af30>] handle_mm_fault+0xde/0x189 > [<c01166d5>] do_page_fault+0x456/0x6ad > [<c0103a43>] error_code+0x2b/0x30 > Out of Memory: Killed process 6672 (RNAsubopt). > RNAsubopt: page allocation failure. order:0, mode:0x1d2 > [<c0103dfd>] dump_stack+0x1e/0x22 > [<c013fd90>] __alloc_pages+0x22c/0x400 > [<c0142368>] do_page_cache_readahead+0x15b/0x1b9 > [<c013c5aa>] filemap_nopage+0x2d4/0x375 > [<c014aa82>] do_no_page+0xc4/0x38c > [<c014af30>] handle_mm_fault+0xde/0x189 > [<c01166d5>] do_page_fault+0x456/0x6ad > [<c0103a43>] error_code+0x2b/0x30
Yep, that's expected. The first stacktrace is from my patch. I added this to see from where the allocation is called. The second trace is from the page fault handler, as the allocation request now returns failed to prevent the second call into oom.
tglx
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |