The oom killer is only invoked when reclaim has already failed and it only kills processes if the victim is also oom. In other words, the oom killer does not select victims when a process tries to allocate from a disjoint cpuset or allocate DMA memory, for example. Therefore, it's pointless for an oom killed process to continue attempting to reclaim memory in a loop when it has been granted access to memory reserves. It can simply return to the page allocator and allocate memory. If there is a very large number of processes trying to reclaim memory, the cond_resched() in shrink_slab() becomes troublesome since it always forces a schedule to other processes also trying to reclaim memory. Compounded by many reclaim loops, it is possible for a process to sit in do_try_to_free_pages() for a very long time when reclaim is pointless and it could allocate if it just returned to the page allocator. This patch checks if current has been oom killed and, if so, aborts futile reclaim immediately. We're not concerned with complete depletion of memory reserves since there's nothing else we can do. Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx> --- mm/vmscan.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2428,6 +2428,14 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, goto out; /* + * If we've been oom killed, reclaim has already failed. We've + * been given access to memory reserves so that we can allocate + * and quickly die, so just abort futile efforts. + */ + if (unlikely(test_thread_flag(TIF_MEMDIE))) + aborted_reclaim = true; + + /* * If we're getting trouble reclaiming, start doing * writepage even in laptop mode. */ -- 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>