linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 19 Mar 2021 17:29:01 +0000	[thread overview]
Message-ID: <20210319172901.cror2u53b7caws3a@ava.usersys.com> (raw)
In-Reply-To: <YFN8wXwJA59w9twA@dhcp22.suse.cz>

Hi Michal,

On Thu 2021-03-18 17:16 +0100, Michal Hocko wrote:
> On Mon 15-03-21 16:58:37, Aaron Tomlin wrote:
> > In the situation where direct reclaim is required to make progress for
> > compaction but no_progress_loops is already over the limit of
> > MAX_RECLAIM_RETRIES consider invoking the oom killer.

Firstly, thank you for your response.

> What is the problem you are trying to fix?

If I understand correctly, in the case of a "costly" order allocation
request that is permitted to repeatedly retry, it is possible to exceed the
maximum reclaim retry threshold as long as "some" progress is being made
even at the highest compaction priority. Furthermore, if the allocator has
a fatal signal pending, this is not considered.

In my opinion, it might be better to just give up straight away or try and
use the OOM killer only in the non-costly order allocation scenario to
assit reclaim. Looking at __alloc_pages_may_oom() the current logic is to
entirely skip the OOM killer for a costly order request, which makes sense.


Regards,

-- 
Aaron Tomlin


  reply	other threads:[~2021-03-19 17:29 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 [this message]
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
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=20210319172901.cror2u53b7caws3a@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).