All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>, rcu <rcu@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Neil Brown <neilb@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH RFC] rcu/tree: Use GFP_MEMALLOC for alloc memory to free memory pattern
Date: Wed, 1 Apr 2020 10:45:56 -0400	[thread overview]
Message-ID: <CAEXW_YTpXojYiskwiqZGHpT45v3xZYhuvy0CubaeyB3fMrmw7g@mail.gmail.com> (raw)
In-Reply-To: <20200401131426.GN3772@suse.de>

On Wed, Apr 1, 2020 at 9:14 AM Mel Gorman <mgorman@suse.de> wrote:
>
> On Wed, Apr 01, 2020 at 09:23:59AM +0200, Michal Hocko wrote:
> > > Can you suggest what prevents other users of GFP_MEMALLOC from doing that
> > > also?
> >
> > There is no explicit mechanism which is indeed unfortunate. The only
> > user real user of the flag is Swap over NFS AFAIK. I have never dared to
> > look into details on how the complete reserves depletion is prevented.
> > Mel would be much better fit here.
> >
>
> It's "prevented" by the fact that every other memory allocation request
> that is not involved with reclaiming memory gets stalled in the allocator
> with only the swap subsystem making any progress until the machine
> recovers. Potentially only kswapd is still running until the system
> recovers if stressed hard enough.
>
> The naming is terrible but is mased on kswapd's use of the PF_MEMALLOC
> flag. For swap-over-nfs, GFP_MEMALLOC saying "this allocation request is
> potentially needed for kswapd to make forward progress and not freeze".
>
> I would not be comfortable with kfree_rcu() doing the same thing because
> there can be many callers in parallel and it's freeing slab objects.
> Swap over NFS should free at least one page, freeing a slab object is
> not guaranteed to free anything.

Got it Mel. Just to clarify to the onlooker. It seemed to fit the
pattern that's why I proposed it as RFC, I was never sure it was the
right approach -- I just proposed it for discussion-sake because I
thought it was worth talking about at least. It was not even merged in
my tree, was just RFC.

Thanks Mel for clarifying the usage of the flag.

 - Joel

  reply	other threads:[~2020-04-01 14:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 13:16 [PATCH RFC] rcu/tree: Use GFP_MEMALLOC for alloc memory to free memory pattern Joel Fernandes (Google)
2020-03-31 14:04 ` Uladzislau Rezki
2020-03-31 15:09   ` Joel Fernandes
2020-03-31 16:01     ` Uladzislau Rezki
2020-03-31 17:02       ` Uladzislau Rezki
2020-03-31 17:49         ` Paul E. McKenney
2020-03-31 18:30       ` Joel Fernandes
2020-04-01 12:25         ` Uladzislau Rezki
2020-04-01 13:47           ` Paul E. McKenney
2020-04-01 18:16             ` Uladzislau Rezki
2020-04-01 18:26               ` Paul E. McKenney
2020-04-01 18:37                 ` Uladzislau Rezki
2020-04-01 18:54                   ` Paul E. McKenney
2020-04-01 19:05                     ` Uladzislau Rezki
2020-04-01 19:34                       ` Paul E. McKenney
2020-04-01 19:35                         ` Uladzislau Rezki
2020-03-31 14:58 ` Joel Fernandes
2020-03-31 15:34   ` Michal Hocko
2020-03-31 16:01     ` Joel Fernandes
2020-03-31 22:19       ` NeilBrown
2020-04-01  3:25         ` Joel Fernandes
2020-04-01  4:52           ` NeilBrown
2020-04-01  7:23       ` Michal Hocko
2020-04-01 11:14         ` joel
2020-04-01 11:14           ` joel
2020-04-01 12:05           ` Michal Hocko
2020-04-01 13:14         ` Mel Gorman
2020-04-01 14:45           ` Joel Fernandes [this message]
2020-04-01 14:45             ` Joel Fernandes
2020-03-31 16:12     ` Uladzislau Rezki
2020-04-01  7:09       ` Michal Hocko
2020-04-01 12:32         ` Uladzislau Rezki
2020-04-01 12:55           ` Michal Hocko
2020-04-01 13:08             ` Uladzislau Rezki
2020-04-01 13:15               ` Michal Hocko
2020-04-01 13:22                 ` Uladzislau Rezki
2020-04-01 15:28                   ` Michal Hocko
2020-04-01 15:46                     ` Uladzislau Rezki
2020-04-01 15:57                     ` Paul E. McKenney
2020-04-01 16:10                       ` 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=CAEXW_YTpXojYiskwiqZGHpT45v3xZYhuvy0CubaeyB3fMrmw7g@mail.gmail.com \
    --to=joel@joelfernandes.org \
    --cc=akpm@linux-foundation.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=neilb@suse.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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.