linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: dsterba@suse.cz, Huaisheng HS1 Ye <yehs1@lenovo.com>,
	Michal Hocko <mhocko@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
	"pasha.tatashin@oracle.com" <pasha.tatashin@oracle.com>,
	"alexander.levin@verizon.com" <alexander.levin@verizon.com>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	"penguin-kernel@I-love.SAKURA.ne.jp"
	<penguin-kernel@I-love.SAKURA.ne.jp>,
	"colyli@suse.de" <colyli@suse.de>,
	NingTing Cheng <chengnt@lenovo.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [External]  Re: [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone
Date: Mon, 7 May 2018 17:25:47 -0700	[thread overview]
Message-ID: <20180508002547.GA16338@bombadil.infradead.org> (raw)
In-Reply-To: <20180507212500.bdphwfhk55w6vlbb@twin.jikos.cz>

On Mon, May 07, 2018 at 11:25:01PM +0200, David Sterba wrote:
> On Mon, May 07, 2018 at 11:44:10AM -0700, Matthew Wilcox wrote:
> > But something like btrfs should almost certainly be using ~GFP_ZONEMASK.
> 
> Agreed, the direct use of __GFP_DMA32 was added in 3ba7ab220e8918176c6f
> to substitute GFP_NOFS, so the allocation flags are less restrictive but
> still acceptable for allocation from slab.
> 
> The requirement from btrfs is to avoid highmem, the 'must be acceptable
> for slab' requirement is more MM internal and should have been hidden
> under some opaque flag mask. There was no strong need for that at the
> time.

The GFP flags encode a multiple of different requirements.  There's
"What can the allocator do to free memory" and "what area of memory
can the allocation come from".  btrfs doesn't actually want to
allocate memory from ZONE_MOVABLE or ZONE_DMA either.  It's probably never
been called with those particular flags set, but in the spirit of
future-proofing btrfs, perhaps a patch like this is in order?

---- >8 ----

Subject: btrfs: Allocate extents from ZONE_NORMAL
From: Matthew Wilcox <mawilcox@microsoft.com>

If anyone ever passes a GFP_DMA or GFP_MOVABLE allocation flag to
allocate_extent_state, it will try to allocate memory from the wrong zone.
We just want to allocate memory from ZONE_NORMAL, so use GFP_RECLAIM_MASK
to get what we want.

Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index e99b329002cf..4e4a67b7b29d 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -216,12 +216,7 @@ static struct extent_state *alloc_extent_state(gfp_t mask)
 {
 	struct extent_state *state;
 
-	/*
-	 * The given mask might be not appropriate for the slab allocator,
-	 * drop the unsupported bits
-	 */
-	mask &= ~(__GFP_DMA32|__GFP_HIGHMEM);
-	state = kmem_cache_alloc(extent_state_cache, mask);
+	state = kmem_cache_alloc(extent_state_cache, mask & GFP_RECLAIM_MASK);
 	if (!state)
 		return state;
 	state->state = 0;

  reply	other threads:[~2018-05-08  0:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04  6:52 [PATCH 0/3] Some fixes for mm code optimization Huaisheng Ye
     [not found] ` <1525416729-108201-4-git-send-email-yehs1@lenovo.com>
2018-05-04 13:18   ` [PATCH 3/3] mm/page_alloc: Fix typo in debug info of calculate_node_totalpages Michal Hocko
2018-05-05  2:10     ` [External] " Huaisheng HS1 Ye
2018-05-09  7:48       ` Michal Hocko
     [not found] ` <1525416729-108201-3-git-send-email-yehs1@lenovo.com>
2018-05-04 13:35   ` [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone Michal Hocko
2018-05-04 15:40     ` Matthew Wilcox
2018-05-04 17:50       ` [External] " Huaisheng HS1 Ye
2018-05-06  9:32       ` Huaisheng HS1 Ye
2018-05-06 13:48         ` Matthew Wilcox
2018-05-06 16:17           ` Huaisheng HS1 Ye
2018-05-06 18:55             ` Matthew Wilcox
2018-05-07 17:16               ` Huaisheng HS1 Ye
2018-05-07 18:44                 ` Matthew Wilcox
2018-05-07 21:25                   ` David Sterba
2018-05-08  0:25                     ` Matthew Wilcox [this message]
2018-05-09  9:36                       ` David Sterba
2018-05-15 11:54                         ` Matthew Wilcox
2018-05-21 17:06                           ` David Sterba
2018-05-09 14:57                     ` Huaisheng HS1 Ye
2018-05-08  0:25                   ` Huaisheng HS1 Ye

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=20180508002547.GA16338@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.levin@verizon.com \
    --cc=chengnt@lenovo.com \
    --cc=colyli@suse.de \
    --cc=dsterba@suse.cz \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=pasha.tatashin@oracle.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=vbabka@suse.cz \
    --cc=yehs1@lenovo.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).