On Sun, 2014-02-16 at 22:50 +0000, Russell King - ARM Linux wrote: > http://www.home.arm.linux.org.uk/~rmk/misc/log-20140208.txt [<c0064ce0>] (__alloc_pages_nodemask+0x0/0x694) from [<c022273c>] (sk_page_frag_refill+0x78/0x108) [<c02226c4>] (sk_page_frag_refill+0x0/0x108) from [<c026a3a4>] (tcp_sendmsg+0x654/0xd1c) r6:00000520 r5:c277bae0 r4:c68f37c0 [<c0269d50>] (tcp_sendmsg+0x0/0xd1c) from [<c028ca9c>] (inet_sendmsg+0x64/0x70) FWIW I had OOMs with the exact same backtrace on kirkwood platform (512MB RAM), but sorry I don't have the full dump anymore. I found a slow leaking process, and since I fixed that leak I now have uptime better than 7 days, *but* there was definitely some memory left when the OOM happened, so it appears to be related to fragmentation. >From what I recall, clearing the page cache helped making the box live a little bit longer. Does it make sense or should alloc_pages() discard its content when trying to satisfy high order allocations ? -- Maxime -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>