From: Aaron Tomlin <atomlin@redhat.com>
To: Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: try oom if reclaim is unable to make forward progress
Date: Thu, 25 Mar 2021 21:01:59 +0000 [thread overview]
Message-ID: <20210325210159.r565fvfitoqeuykp@ava.usersys.com> (raw)
In-Reply-To: <YFh10eSTKY5lbE9u@dhcp22.suse.cz>
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?
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:
#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
next prev parent reply other threads:[~2021-03-25 21:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 16:58 [PATCH] mm/page_alloc: try oom if reclaim is unable to make forward progress Aaron Tomlin
2021-03-15 19:54 ` kernel test robot
2021-03-15 19:54 ` kernel test robot
2021-03-15 19:54 ` kernel test robot
2021-03-15 19:54 ` kernel test robot
2021-03-15 19:54 ` kernel test robot
2021-03-15 19:54 ` kernel test robot
2021-03-18 16:16 ` Michal Hocko
2021-03-19 17:29 ` Aaron Tomlin
2021-03-22 10:47 ` Michal Hocko
2021-03-25 21:01 ` Aaron Tomlin [this message]
2021-03-26 8:16 ` Michal Hocko
2021-03-26 11:22 ` Aaron Tomlin
2021-03-26 15:36 ` Michal Hocko
2021-03-26 17:00 ` Aaron Tomlin
2021-05-18 14:05 ` Aaron Tomlin
2021-05-19 11:10 ` Michal Hocko
2021-05-19 13:06 ` Aaron Tomlin
2021-05-19 14:50 ` [PATCH] mm/page_alloc: bail out on fatal signal during reclaim/compaction retry attempt Aaron Tomlin
2021-05-19 15:22 ` Vlastimil Babka
2021-05-19 19:08 ` Aaron Tomlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210325210159.r565fvfitoqeuykp@ava.usersys.com \
--to=atomlin@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.