Re: More OOM problems

[Vlastimil Babka <vbabka@suse.cz>]

On 09/18/2016 10:03 PM, Linus Torvalds wrote:
> [ More or less random collection of people from previous oom patches 
> and/or discussions, if you feel you shouldn't have been cc'd, blame
> me for just picking things from earlier threads and/or commits ]
> 
> I'm afraid that the oom situation is still not fixed, and the "let's 
> die quickly" patches are still a nasty regression.

So I'm trying to understand the core of the regression compared to
pre-4.7. It can't be the compaction feedback, as that was reverted, and
compaction itself shouldn't perform worse than pre-4.7. This leaves us
with should_reclaim_retry() false. This can return false if:

1) no_progress_loops > MAX_RECLAIM_RETRIES

But we have in __allow_pages_slowpath() this:

if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER)
no_progress_loops = 0;

I doubt reclaim makes no progress in your case, and the non-costly order
is also true. So, unlikely.

2) The watermark check that includes estimate for pages available for
reclaim fails.

Could be the backoff in calculation of "available" in
should_reclaim_retry() is too aggressive. But it depends on the
no_progress_loops which I think is 0 (see above). Again, unlikely.

But the watermark check doesn't actually work for order-1+ allocations,
the "available" estimate only affects order-0 check. For higher orders
it will be false if the page of sufficient order doesn't already exist.
That's fine if we trust should_compact_retry() in such case.

But Joonsoo already had a theoretical scenario where this can fall apart:
http://lkml.kernel.org/r/<20160824050157.GA22781@js1304-P5Q-DELUXE>

See the part that starts at "Assume following situation:". I suspect
something like that happened here.

I think at least temporarily we'll have to make the watermark check
to be order-0 check for non-costly orders.

Something like below (untested)?

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a2214c64ed3c..9b3b3a79c58a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3347,17 +3347,24 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
 					ac->nodemask) {
 		unsigned long available;
 		unsigned long reclaimable;
+		int check_order = order;
+		unsigned long watermark = min_wmark_pages(zone);
 
 		available = reclaimable = zone_reclaimable_pages(zone);
 		available -= DIV_ROUND_UP(no_progress_loops * available,
 					  MAX_RECLAIM_RETRIES);
 		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
 
+		if (order > 0 && order <= PAGE_ALLOC_COSTLY_ORDER) {
+			check_order = 0;
+			watermark += 1UL << order;
+		}
+
 		/*
 		 * Would the allocation succeed if we reclaimed the whole
 		 * available?
 		 */
-		if (__zone_watermark_ok(zone, order, min_wmark_pages(zone),
+		if (__zone_watermark_ok(zone, check_order, watermark,
 				ac_classzone_idx(ac), alloc_flags, available)) {
 			/*
 			 * If we didn't make any progress and have a lot of

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>