mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 11:40:53 +07:00
mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change
Historically, !__GFP_FS allocations were not allowed to invoke the OOM killer once reclaim had failed, but nevertheless kept looping in the allocator. Commit9879de7373
("mm: page_alloc: embed OOM killing naturally into allocation slowpath"), which should have been a simple cleanup patch, accidentally changed the behavior to aborting the allocation at that point. This creates problems with filesystem callers (?) that currently rely on the allocator waiting for other tasks to intervene. Revert the behavior as it shouldn't have been changed as part of a cleanup patch. Fixes:9879de7373
("mm: page_alloc: embed OOM killing naturally into allocation slowpath") Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.cz> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Dave Chinner <david@fromorbit.com> Acked-by: David Rientjes <rientjes@google.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> [3.19.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
39afb5ee46
commit
cc87317726
@ -2353,8 +2353,15 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
|
||||
if (ac->high_zoneidx < ZONE_NORMAL)
|
||||
goto out;
|
||||
/* The OOM killer does not compensate for light reclaim */
|
||||
if (!(gfp_mask & __GFP_FS))
|
||||
if (!(gfp_mask & __GFP_FS)) {
|
||||
/*
|
||||
* XXX: Page reclaim didn't yield anything,
|
||||
* and the OOM killer can't be invoked, but
|
||||
* keep looping as per should_alloc_retry().
|
||||
*/
|
||||
*did_some_progress = 1;
|
||||
goto out;
|
||||
}
|
||||
/*
|
||||
* GFP_THISNODE contains __GFP_NORETRY and we never hit this.
|
||||
* Sanity check for bare calls of __GFP_THISNODE, not real OOM.
|
||||
|
Loading…
Reference in New Issue
Block a user