The patch titled
mm: invoke oom killer for __GFP_NOFAIL
has been removed from the -mm tree. Its filename was
mm-invoke-oom-killer-for-__gfp_nofail.patch
This patch was dropped because an updated version will be merged
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: mm: invoke oom killer for __GFP_NOFAIL
From: David Rientjes <rientjes@xxxxxxxxxx>
The oom killer must be invoked regardless of the order if the allocation
is __GFP_NOFAIL, otherwise it will loop forever when reclaim fails to free
some memory.
Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx>
Acked-by: Mel Gorman <mel@xxxxxxxxx>
Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Cc: Nick Piggin <npiggin@xxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx>
Cc: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
Acked-by: Rik van Riel <riel@xxxxxxxxxx>
Cc: Minchan Kim <minchan.kim@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/page_alloc.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff -puN mm/page_alloc.c~mm-invoke-oom-killer-for-__gfp_nofail mm/page_alloc.c
--- a/mm/page_alloc.c~mm-invoke-oom-killer-for-__gfp_nofail
+++ a/mm/page_alloc.c
@@ -1547,7 +1547,7 @@ __alloc_pages_may_oom(gfp_t gfp_mask, un
goto out;
/* The OOM killer will not help higher order allocs */
- if (order > PAGE_ALLOC_COSTLY_ORDER)
+ if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_NOFAIL))
goto out;
/* Exhausted what can be done so it's blamo time */
@@ -1763,16 +1763,12 @@ rebalance:
migratetype);
if (page)
goto got_pg;
+ if ((gfp_mask & __GFP_NOFAIL) ||
+ order <= PAGE_ALLOC_COSTLY_ORDER)
+ goto restart;
- /*
- * The OOM killer does not trigger for high-order allocations
- * but if no progress is being made, there are no other
- * options and retrying is unlikely to help
- */
- if (order > PAGE_ALLOC_COSTLY_ORDER)
- goto nopage;
-
- goto restart;
+ /* No freeing is possible so just fail */
+ goto nopage;
}
}
_
Patches currently in -mm which might be from rientjes@xxxxxxxxxx are
linux-next.patch
cpusets-restructure-the-function-cpuset_update_task_memory_state.patch
cpusets-update-tasks-page-slab-spread-flags-in-time.patch
cpusetmm-update-tasks-mems_allowed-in-time.patch
cpusetmm-update-tasks-mems_allowed-in-time-fix.patch
cpusetmm-update-tasks-mems_allowed-in-time-cleanup.patch
page-allocator-use-a-pre-calculated-value-instead-of-num_online_nodes-in-fast-paths-do-not-override-definition-of-node_set_online-with-macro.patch
mm-setup_per_zone_inactive_ratio-do-not-call-for-int_sqrt-if-not-needed.patch
mm-setup_per_zone_inactive_ratio-fix-comment-and-make-it-__init.patch
oom-fix-possible-oom_dump_tasks-null-pointer.patch
oom-move-oom_adj-value-from-task_struct-to-mm_struct.patch
oom-prevent-possible-oom_disable-livelock.patch
mm-invoke-oom-killer-for-__gfp_nofail.patch
memcg-add-file-based-rss-accounting.patch
memcg-add-file-based-rss-accounting-fix-mem_cgroup_update_mapped_file_stat-oops.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
