From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 324156B000C for ; Mon, 7 May 2018 20:25:54 -0400 (EDT) Received: by mail-pf0-f200.google.com with SMTP id q15so3337606pff.17 for ; Mon, 07 May 2018 17:25:54 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2607:7c80:54:e::133]) by mx.google.com with ESMTPS id c129si23596696pfa.99.2018.05.07.17.25.51 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 07 May 2018 17:25:51 -0700 (PDT) Date: Mon, 7 May 2018 17:25:47 -0700 From: Matthew Wilcox Subject: Re: [External] Re: [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone Message-ID: <20180508002547.GA16338@bombadil.infradead.org> References: <1525416729-108201-3-git-send-email-yehs1@lenovo.com> <20180504133533.GR4535@dhcp22.suse.cz> <20180504154004.GB29829@bombadil.infradead.org> <20180506134814.GB7362@bombadil.infradead.org> <20180506185532.GA13604@bombadil.infradead.org> <20180507184410.GA12361@bombadil.infradead.org> <20180507212500.bdphwfhk55w6vlbb@twin.jikos.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180507212500.bdphwfhk55w6vlbb@twin.jikos.cz> Sender: owner-linux-mm@kvack.org List-ID: To: dsterba@suse.cz, Huaisheng HS1 Ye , Michal Hocko , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "vbabka@suse.cz" , "mgorman@techsingularity.net" , "pasha.tatashin@oracle.com" , "alexander.levin@verizon.com" , "hannes@cmpxchg.org" , "penguin-kernel@I-love.SAKURA.ne.jp" , "colyli@suse.de" , NingTing Cheng , "linux-kernel@vger.kernel.org" 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 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 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;