From: Vlastimil Babka <vbabka@suse.cz>
To: Aaron Tomlin <atomlin@redhat.com>, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, mhocko@suse.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: bail out on fatal signal during reclaim/compaction retry attempt
Date: Wed, 19 May 2021 17:22:29 +0200 [thread overview]
Message-ID: <076e1c68-b4a2-26ea-9538-d88e6da800cc@suse.cz> (raw)
In-Reply-To: <20210519145014.3220164-1-atomlin@redhat.com>
On 5/19/21 4:50 PM, Aaron Tomlin wrote:
> It does not make sense to retry compaction when the last known compact
> result was skipped and a fatal signal is pending.
>
> In the context of try_to_compact_pages(), indeed COMPACT_SKIPPED can be
> returned; albeit, not every zone, on the zone list, would be considered
> in the case a fatal signal is found to be pending.
> Yet, in should_compact_retry(), given the last known compaction result,
> each zone, on the zone list, can be considered/or checked
> (see compaction_zonelist_suitable()). For example, if a zone was found
> to succeed, then reclaim/compaction would be tried again
> (notwithstanding the above).
>
> This patch ensures that compaction is not needlessly retried when the
> last known compaction result was skipped and in the unlikely case a
> fatal signal is found pending. So, OOM is at least attempted.
>
> Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
Hm, indeed, if fatal_signal_pending() is true then try_to_compact_pages() will
bail out in the for-each-zone loop after trying a single zone and if that zone
keeps returning COMPACT_SKIPPED, things can get stuck.
And direct reclaim might see compaction_ready() for another zone and return 1,
faking the progress.
So your patch seems to be solving the issue. But maybe we should just do the
test at the beginning of should_compact_retry() and not specific to
compaction_needs_reclaim() - if there's a fatal signal, there will be no
compaction happening, so we should just say not to retry.
I suppose if the patch fixes your situation where fatal_signal_pending() was
true, there's hopefully not a more general problem with the retry logic?
> ---
> mm/page_alloc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index aaa1655cf682..5f9aac27a1b5 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4268,6 +4268,8 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags,
> * to work with, so we retry only if it looks like reclaim can help.
> */
> if (compaction_needs_reclaim(compact_result)) {
> + if (fatal_signal_pending(current))
> + goto out;
> ret = compaction_zonelist_suitable(ac, order, alloc_flags);
> goto out;
> }
>
next prev parent reply other threads:[~2021-05-19 15:22 UTC|newest]
Thread overview: 18+ 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-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
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 [this message]
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=076e1c68-b4a2-26ea-9538-d88e6da800cc@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=atomlin@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox