[PATCH 4/3] mm, oom: drop the last allocation attempt before out_of_memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Michal Hocko <mhocko@xxxxxxxx>

__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 <mhocko@xxxxxxxx>
---
 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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]