Re: [PATCH] mm/page_alloc: try oom if reclaim is unable to make forward progress

From: Michal Hocko
Date: Fri Mar 26 2021 - 04:17:13 EST


[Cc Vlastimil]

On Thu 25-03-21 21:01:59, Aaron Tomlin wrote:
> On Mon 2021-03-22 11:47 +0100, Michal Hocko wrote:
> > Costly orders already do have heuristics for the retry in place. Could
> > you be more specific what kind of problem you see with those?
>
> If I understand correctly, when the gfp_mask consists of
> GFP_KERNEL | __GFP_RETRY_MAYFAIL in particular, an allocation request will
> fail, if and only if reclaim is unable to make progress.
>
> The costly order allocation retry logic is handled primarily in
> should_reclaim_retry(). Looking at should_reclaim_retry() we see that the
> no progress counter value is always incremented in the costly order case
> even when "some" progress has been made which is represented by the value
> stored in did_some_progress.
>
> if (costly_order && !(gfp_mask & __GFP_RETRY_MAYFAIL))
> goto nopage;
>
> if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
> did_some_progress > 0, &no_progress_loops))
> goto retry;
>
> I think after we have tried MAX_RECLAIM_RETRIES in a row without success
> and the last known compaction attempt was "skipped", perhaps it would be
> better to try and use the OOM killer or fail the allocation attempt?

The oom killer is never triggered for costly allocation request. Both
reclaim and compaction maintain their own retries counters as they are
targeting a different operation. Although the compaction really depends
on the reclaim to do some progress.

> I encountered a situation when the value of no_progress_loops was found to
> be 31,611,688 i.e. significantly over MAX_RECLAIM_RETRIES; the allocation
> order was 5. The gfp_mask contained the following:

OK, this sound unexpected as it indicates that the reclaim is able to
make a forward progress but compaction doesn't want to give up and keeps
retrying. Are you able to reproduce this or could you find out which
specific condition keeps compaction retrying? I would expect that it is
one of the 3 conditions before the max_retries is checked.

> #define ___GFP_HIGHMEM 0x02
> #define ___GFP_IO 0x40
> #define ___GFP_FS 0x80
> #define ___GFP_NOWARN 0x200
> #define ___GFP_RETRY_MAYFAIL 0x400
> #define ___GFP_COMP 0x4000
> #define ___GFP_HARDWALL 0x20000
> #define ___GFP_DIRECT_RECLAIM 0x200000
> #define ___GFP_KSWAPD_RECLAIM 0x400000
>
>
>
> --
> Aaron Tomlin
>

--
Michal Hocko
SUSE Labs