All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	rcu@vger.kernel.org, willy@infradead.org, peterz@infradead.org,
	neilb@suse.com, vbabka@suse.cz, mgorman@suse.de,
	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 15:08:16 +0200	[thread overview]
Message-ID: <20200401130816.GA1320@pc636> (raw)
In-Reply-To: <20200401125503.GJ22681@dhcp22.suse.cz>

On Wed, Apr 01, 2020 at 02:55:03PM +0200, Michal Hocko wrote:
> On Wed 01-04-20 14:32:30, Uladzislau Rezki wrote:
> > On Wed, Apr 01, 2020 at 09:09:58AM +0200, Michal Hocko wrote:
> > > On Tue 31-03-20 18:12:15, Uladzislau Rezki wrote:
> > > > > 
> > > > > __GFP_ATOMIC | __GFP_HIGH is the way to get an additional access to
> > > > > memory reserves regarless of the sleeping status.
> > > > > 
> > > > Michal, just one question here regarding proposed flags. Can we also
> > > > tight it with __GFP_RETRY_MAYFAIL flag? Means it also can repeat a few
> > > > times in order to increase the chance of being success.
> > > 
> > > yes, __GFP_RETRY_MAYFAIL is perfectly valid with __GFP_ATOMIC. Please
> > > note that __GFP_ATOMIC, despite its name, doesn't imply an atomic
> > > allocation which cannot sleep. Quite confusing, I know. A much better
> > > name would be __GFP_RESERVES or something like that.
> > > 
> > OK. Then we can use GFP_ATOMIC | __GFP_RETRY_MAYFAIL to try in more harder
> > way.
> 
> Please note the difference between __GFP_ATOMIC and GFP_ATOMIC. The
> later is a highlevel flag to use for atomic contexts. The former is an
> explicit way to give an access to memory reserves. I am not familiar
> with your code but if you have an existing gfp context coming from the
> caller then just do (gfp | __GFP_ATOMIC | __GFP_HIGH | __GFP_RETRY_MAYFAIL).
> If you do not have any gfp then decide based on whether the current
> context is allowed to sleep
> 	gfp = GFP_KERNEL | __GFP_ATOMIC | __GFP_HIGH | __GFP_RETRY_MAYFAIL;
> 	if (!sleepable)
> 		gfp &= ~__GFP_DIRECT_RECLAIM;

We call it from atomic context, so we can not sleep, also we do not have
any existing context coming from the caller. I see that GFP_ATOMIC is high-level
flag and is differ from __GFP_ATOMIC. It is defined as:

#define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)

so basically we would like to have __GFP_KSWAPD_RECLAIM that is included in it,
because it will also help in case of high memory pressure and wake-up kswapd to
reclaim memory.

We also can extract:

__GFP_ATOMIC | __GFP_HIGH | __GFP_RETRY_MAYFAIL | __GFP_KSWAPD_RECLAIM

but that is longer then

GFP_ATMOC |  __GFP_RETRY_MAYFAIL

Am i missing something?

Thank you, Michal!

--
Vlad Rezki

  reply	other threads:[~2020-04-01 13:08 UTC|newest]

Thread overview: 39+ 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
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 [this message]
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=20200401130816.GA1320@pc636 \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --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.