summaryrefslogtreecommitdiffstats
path: root/mm/page_alloc.c
diff options
context:
space:
mode:
authorMichal Hocko <mhocko@suse.com>2017-07-12 17:36:45 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2017-07-12 19:26:03 -0400
commitdcda9b04713c3f6ff0875652924844fae28286ea (patch)
tree0aa6dd3854b67e881e8be74283f0ae6ff96245ac /mm/page_alloc.c
parent473738eb78c3e379d682fb8a3cf7e1d17beded9f (diff)
mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic
__GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to the page allocator. This has been true but only for allocations requests larger than PAGE_ALLOC_COSTLY_ORDER. It has been always ignored for smaller sizes. This is a bit unfortunate because there is no way to express the same semantic for those requests and they are considered too important to fail so they might end up looping in the page allocator for ever, similarly to GFP_NOFAIL requests. Now that the whole tree has been cleaned up and accidental or misled usage of __GFP_REPEAT flag has been removed for !costly requests we can give the original flag a better name and more importantly a more useful semantic. Let's rename it to __GFP_RETRY_MAYFAIL which tells the user that the allocator would try really hard but there is no promise of a success. This will work independent of the order and overrides the default allocator behavior. Page allocator users have several levels of guarantee vs. cost options (take GFP_KERNEL as an example) - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_ attempt to free memory at all. The most light weight mode which even doesn't kick the background reclaim. Should be used carefully because it might deplete the memory and the next user might hit the more aggressive reclaim - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic allocation without any attempt to free memory from the current context but can wake kswapd to reclaim memory if the zone is below the low watermark. Can be used from either atomic contexts or when the request is a performance optimization and there is another fallback for a slow path. - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) - non sleeping allocation with an expensive fallback so it can access some portion of memory reserves. Usually used from interrupt/bh context with an expensive slow path fallback. - GFP_KERNEL - both background and direct reclaim are allowed and the _default_ page allocator behavior is used. That means that !costly allocation requests are basically nofail but there is no guarantee of that behavior so failures have to be checked properly by callers (e.g. OOM killer victim is allowed to fail currently). - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior and all allocation requests fail early rather than cause disruptive reclaim (one round of reclaim in this implementation). The OOM killer is not invoked. - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator behavior and all allocation requests try really hard. The request will fail if the reclaim cannot make any progress. The OOM killer won't be triggered. - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior and all allocation requests will loop endlessly until they succeed. This might be really dangerous especially for larger orders. Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL because they already had their semantic. No new users are added. __alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if there is no progress and we have already passed the OOM point. This means that all the reclaim opportunities have been exhausted except the most disruptive one (the OOM killer) and a user defined fallback behavior is more sensible than keep retrying in the page allocator. [akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c] [mhocko@suse.com: semantic fix] Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz [mhocko@kernel.org: address other thing spotted by Vlastimil] Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Alex Belits <alex.belits@cavium.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: David Daney <david.daney@cavium.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@suse.de> Cc: NeilBrown <neilb@suse.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/page_alloc.c')
-rw-r--r--mm/page_alloc.c14
1 files changed, 11 insertions, 3 deletions
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 64b7d82a9b1a..6d30e914afb6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3284,6 +3284,14 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
3284 /* The OOM killer will not help higher order allocs */ 3284 /* The OOM killer will not help higher order allocs */
3285 if (order > PAGE_ALLOC_COSTLY_ORDER) 3285 if (order > PAGE_ALLOC_COSTLY_ORDER)
3286 goto out; 3286 goto out;
3287 /*
3288 * We have already exhausted all our reclaim opportunities without any
3289 * success so it is time to admit defeat. We will skip the OOM killer
3290 * because it is very likely that the caller has a more reasonable
3291 * fallback than shooting a random task.
3292 */
3293 if (gfp_mask & __GFP_RETRY_MAYFAIL)
3294 goto out;
3287 /* The OOM killer does not needlessly kill tasks for lowmem */ 3295 /* The OOM killer does not needlessly kill tasks for lowmem */
3288 if (ac->high_zoneidx < ZONE_NORMAL) 3296 if (ac->high_zoneidx < ZONE_NORMAL)
3289 goto out; 3297 goto out;
@@ -3413,7 +3421,7 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags,
3413 } 3421 }
3414 3422
3415 /* 3423 /*
3416 * !costly requests are much more important than __GFP_REPEAT 3424 * !costly requests are much more important than __GFP_RETRY_MAYFAIL
3417 * costly ones because they are de facto nofail and invoke OOM 3425 * costly ones because they are de facto nofail and invoke OOM
3418 * killer to move on while costly can fail and users are ready 3426 * killer to move on while costly can fail and users are ready
3419 * to cope with that. 1/4 retries is rather arbitrary but we 3427 * to cope with that. 1/4 retries is rather arbitrary but we
@@ -3920,9 +3928,9 @@ retry:
3920 3928
3921 /* 3929 /*
3922 * Do not retry costly high order allocations unless they are 3930 * Do not retry costly high order allocations unless they are
3923 * __GFP_REPEAT 3931 * __GFP_RETRY_MAYFAIL
3924 */ 3932 */
3925 if (costly_order && !(gfp_mask & __GFP_REPEAT)) 3933 if (costly_order && !(gfp_mask & __GFP_RETRY_MAYFAIL))
3926 goto nopage; 3934 goto nopage;
3927 3935
3928 if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags, 3936 if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,