All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: 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 14:55:03 +0200	[thread overview]
Message-ID: <20200401125503.GJ22681@dhcp22.suse.cz> (raw)
In-Reply-To: <20200401123230.GB32593@pc636>

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;
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2020-04-01 12:55 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
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 [this message]
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=20200401125503.GJ22681@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --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=neilb@suse.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=urezki@gmail.com \
    --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.