Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 1 Apr 2020 17:28:05 +0200
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
Message-ID: <20200401152805.GN22681@dhcp22.suse.cz>
References: <20200331131628.153118-1-joel@joelfernandes.org>
 <20200331145806.GB236678@google.com>
 <20200331153450.GM30449@dhcp22.suse.cz>
 <20200331161215.GA27676@pc636>
 <20200401070958.GB22681@dhcp22.suse.cz>
 <20200401123230.GB32593@pc636>
 <20200401125503.GJ22681@dhcp22.suse.cz>
 <20200401130816.GA1320@pc636>
 <20200401131528.GK22681@dhcp22.suse.cz>
 <20200401132258.GA1953@pc636>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200401132258.GA1953@pc636>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed 01-04-20 15:22:58, Uladzislau Rezki wrote:
> > > 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
> > 
> > OK, if you are always in the atomic context then GFP_ATOMIC is
> > sufficient. __GFP_RETRY_MAYFAIL will make no difference for allocations
> > which do not reclaim (and thus not retry). Sorry this was not clear to
> > me from the previous description.
> > 
> Ahh. OK. Then adding __GFP_RETRY_MAYFAIL to GFP_ATOMIC will not make any effect.
> 
> Thank you for your explanation!

Welcome. I wish all those gfp flags were really clear but I fully
understand that people who are not working with MM regurarly might find
it confusing. Btw. have __GFP_RETRY_MAYFAIL is documented in gfp.h and
it is documented as the reclaim modifier which should imply that it has
no effect when the reclaim is not allowed which is the case for any non
sleeping allocation. If that relation was not immediately obvious then I
think we need to make it explicit. Would you find it useful?

E.g.

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index e3ab1c0d9140..8f09cefdfa7b 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -127,6 +127,8 @@ struct vm_area_struct;
  *
  * Reclaim modifiers
  * ~~~~~~~~~~~~~~~~~
+ * Please note that all the folloging flags are only applicable to sleepable
+ * allocations (e.g. %GFP_NOWAIT and %GFP_ATOMIC will ignore them).
  *
  * %__GFP_IO can start physical IO.
  *
-- 
Michal Hocko
SUSE Labs