All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm, oom: stop reclaiming if GFP_ATOMIC will start failing soon
Date: Mon, 27 Apr 2020 16:03:56 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2004271558540.248401@chino.kir.corp.google.com> (raw)
In-Reply-To: <20200427133051.b71f961c1bc53a8e72c4f003@linux-foundation.org>

On Mon, 27 Apr 2020, Andrew Morton wrote:

> > No - that would actually make the problem worse.
> > 
> > Today, per-zone min watermarks dictate when user allocations will loop or 
> > oom kill.  should_reclaim_retry() currently loops if reclaim has succeeded 
> > in the past few tries and we should be able to allocate if we are able to 
> > reclaim the amount of memory that we think we can.
> > 
> > The issue is that this supposes that looping to reclaim more will result 
> > in more free memory.  That doesn't always happen if there are concurrent 
> > memory allocators.
> > 
> > GFP_ATOMIC allocators can access below these per-zone watermarks.  So the 
> > issue is that per-zone free pages stays between ALLOC_HIGH watermarks 
> > (the watermark that GFP_ATOMIC allocators can allocate to) and min 
> > watermarks.  We never reclaim enough memory to get back to min watermarks 
> > because reclaim cannot keep up with the amount of GFP_ATOMIC allocations.
> 
> But there should be an upper bound upon the total amount of in-flight
> GFP_ATOMIC memory at any point in time?  These aren't like pagecache
> which will take more if we give it more.  Setting the various
> thresholds appropriately should ensure that blockable allocations don't
> get their memory stolen by GPP_ATOMIC allocations?
> 

Certainly if that upper bound is defined and enforced somewhere we would 
not have run into this issue causing all userspace to become completely 
unresponsive.  Do you have links to patches that proposed enforcing this 
upper bound?  It seems like it would have to be generic to 
__alloc_pages_slowpath() because otherwise multiple different GFP_ATOMIC 
allocators, all from different sources, couldn't orchestrate their memory 
allocations amongst themselves to enforce this upper bound.  They would 
need to work together to ensure they don't conspire to cause this 
depletion.  I'd be happy to take a look if there are links to other 
approaches.

  reply	other threads:[~2020-04-27 23:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 20:48 [patch] mm, oom: stop reclaiming if GFP_ATOMIC will start failing soon David Rientjes
2020-04-24 20:48 ` David Rientjes
2020-04-25  0:32 ` Tetsuo Handa
2020-04-26  0:27 ` Andrew Morton
2020-04-26  3:04   ` Tetsuo Handa
2020-04-27  3:12   ` David Rientjes
2020-04-27  3:12     ` David Rientjes
2020-04-27  5:03     ` Tetsuo Handa
2020-04-27 20:30     ` Andrew Morton
2020-04-27 23:03       ` David Rientjes [this message]
2020-04-27 23:03         ` David Rientjes
2020-04-27 23:35         ` Andrew Morton
2020-04-28  7:43           ` Michal Hocko
2020-04-29  8:31             ` peter enderborg
2020-04-29  9:00               ` Michal Hocko
2020-04-28  9:38       ` Vlastimil Babka
2020-04-28 21:48         ` David Rientjes
2020-04-28 21:48           ` David Rientjes
2020-04-28 23:37           ` Tetsuo Handa
2020-04-29  7:51           ` Vlastimil Babka
2020-04-29  9:04             ` Michal Hocko
2020-04-29 10:45               ` Tetsuo Handa
2020-04-29 11:43                 ` Michal Hocko
2020-04-27  8:20   ` peter enderborg
2020-04-27 15:01 ` Michal Hocko

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=alpine.DEB.2.22.394.2004271558540.248401@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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.