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:   Mon, 6 Apr 2020 16:32:34 -0700 (PDT)
From:   David Rientjes <rientjes@google.com>
To:     John Hubbard <jhubbard@nvidia.com>
cc:     Michal Hocko <mhocko@kernel.org>, NeilBrown <neilb@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Joel Fernandes <joel@joelfernandes.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm: clarify __GFP_MEMALLOC usage
In-Reply-To: <4f861f07-4b47-8ddc-f783-10201ea302d3@nvidia.com>
Message-ID: <alpine.DEB.2.21.2004061626540.45667@chino.kir.corp.google.com>
References: <20200403083543.11552-1-mhocko@kernel.org> <20200403083543.11552-2-mhocko@kernel.org> <alpine.DEB.2.21.2004031238571.230548@chino.kir.corp.google.com> <87blo8xnz2.fsf@notabene.neil.brown.name> <20200406070137.GC19426@dhcp22.suse.cz>
 <4f861f07-4b47-8ddc-f783-10201ea302d3@nvidia.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 6 Apr 2020, John Hubbard wrote:

> Hi Michal and all,
> 
> How about using approximately this wording instead? I found Neil's wording to
> be
> especially helpful so I mixed it in. (Also fixed a couple of slight 80-col
> overruns.)
> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index be2754841369..c247a911d8c7 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -111,6 +111,15 @@ struct vm_area_struct;
>   * very shortly e.g. process exiting or swapping. Users either should
>   * be the MM or co-ordinating closely with the VM (e.g. swap over NFS).
>   *
> + * To be extra clear: users of __GFP_MEMALLOC must be working to free other
> + * memory, and that other memory needs to be freed "soon"; specifically,
> before
> + * the reserve is exhausted. This generally implies a throttling mechanism
> that
> + * balances the amount of __GFP_MEMALLOC memory used against the amount that
> the
> + * caller is about to free.
> + *
> + * Usage of a pre-allocated pool (e.g. mempool) should be always considered
> + * before using this flag.
> + *
>   * %__GFP_NOMEMALLOC is used to explicitly forbid access to emergency
> reserves.
>   * This takes precedence over the %__GFP_MEMALLOC flag if both are set.
>   */

I agree this looks better, but if a developer is reading this and is 
unfamiliar with the implementation of memory reserves or __GFP_MEMALLOC, 
how do they take any action that memory allocated with this bit is freed 
before the reserve is exhausted?

It seems like it's simply saying "don't allocate a lot of this before you 
free it."  That may be very well how it goes, but any discussion of 
depletion of the reserve seems to imply we'd want to quantify it and I 
agree that's not what we want the user to do.

So maybe simply state that reserves can be extremely limited and thus it's 
best to assume there is very little reserve left?