From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by kanga.kvack.org (Postfix) with ESMTP id E1C176B0009 for ; Thu, 28 Jan 2016 15:40:13 -0500 (EST) Received: by mail-wm0-f54.google.com with SMTP id l66so27877281wml.0 for ; Thu, 28 Jan 2016 12:40:13 -0800 (PST) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com. [74.125.82.66]) by mx.google.com with ESMTPS id 137si6423972wmb.8.2016.01.28.12.40.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jan 2016 12:40:12 -0800 (PST) Received: by mail-wm0-f66.google.com with SMTP id r129so6029664wmr.0 for ; Thu, 28 Jan 2016 12:40:12 -0800 (PST) From: Michal Hocko Subject: [PATCH 4/3] mm, oom: drop the last allocation attempt before out_of_memory Date: Thu, 28 Jan 2016 21:40:03 +0100 Message-Id: <1454013603-3682-1-git-send-email-mhocko@kernel.org> In-Reply-To: <1450203586-10959-1-git-send-email-mhocko@kernel.org> References: <1450203586-10959-1-git-send-email-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Hillf Danton , KAMEZAWA Hiroyuki , linux-mm@kvack.org, LKML , Michal Hocko From: Michal Hocko __alloc_pages_may_oom has been doing get_page_from_freelist with ALLOC_WMARK_HIGH target before going out_of_memory and invoking the oom killer. This has two reasons as explained by Andrea: " : the reason for the high wmark is to reduce the likelihood of livelocks : and be sure to invoke the OOM killer, if we're still under pressure : and reclaim just failed. The high wmark is used to be sure the failure : of reclaim isn't going to be ignored. If using the min wmark like : you propose there's risk of livelock or anyway of delayed OOM killer : invocation. : : The reason for doing one last wmark check (regardless of the wmark : used) before invoking the oom killer, was just to be sure another OOM : killer invocation hasn't already freed a ton of memory while we were : stuck in reclaim. A lot of free memory generated by the OOM killer, : won't make a parallel reclaim more likely to succeed, it just creates : free memory, but reclaim only succeeds when it finds "freeable" memory : and it makes progress in converting it to free memory. So for the : purpose of this last check, the high wmark would work fine as lots of : free memory would have been generated in such case. " This is no longer a concern after "mm, oom: rework oom detection" because should_reclaim_retry performs the water mark check right before __alloc_pages_may_oom is invoked. Remove the last moment allocation request as it just makes the code more confusing and doesn't really serve any purpose because a success is basically impossible otherwise should_reclaim_retry would force the reclaim to retry. So this is merely a code cleanup rather than a functional change. Signed-off-by: Michal Hocko --- mm/page_alloc.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 268de1654128..f82941c0ac4e 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2743,16 +2743,6 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, return NULL; } - /* - * Go through the zonelist yet one more time, keep very high watermark - * here, this is only to catch a parallel oom killing, we must fail if - * we're still under heavy pressure. - */ - page = get_page_from_freelist(gfp_mask | __GFP_HARDWALL, order, - ALLOC_WMARK_HIGH|ALLOC_CPUSET, ac); - if (page) - goto out; - if (!(gfp_mask & __GFP_NOFAIL)) { /* Coredumps can quickly deplete all memory reserves */ if (current->flags & PF_DUMPCORE) -- 2.7.0.rc3 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org