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:   Thu, 19 Mar 2020 18:01:52 +0100
From:   Michal Hocko <mhocko@kernel.org>
To:     Rik van Riel <riel@surriel.com>
Cc:     Roman Gushchin <guro@fb.com>, Aslan Bakirov <aslan@fb.com>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        kernel-team@fb.com, linux-kernel@vger.kernel.org,
        Andreas Schaufler <andreas.schaufler@gmx.de>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Guido =?iso-8859-1?Q?G=FCnther?= <agx@sigxcpu.org>,
        Naresh Kamboju <naresh.kamboju@linaro.org>
Subject: Re: [PATCH] mm: hugetlb: fix hugetlb_cma_reserve() if CONFIG_NUMA
 isn't set
Message-ID: <20200319170152.GJ20800@dhcp22.suse.cz>
References: <20200318153424.3202304-1-guro@fb.com>
 <20200318161625.GR21362@dhcp22.suse.cz>
 <20200318175529.GA6263@carbon.dhcp.thefacebook.com>
 <20200319161644.GH20800@dhcp22.suse.cz>
 <3f75f55dc6a9b4dfd3c6ac808c370bfd91d1554a.camel@surriel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3f75f55dc6a9b4dfd3c6ac808c370bfd91d1554a.camel@surriel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu 19-03-20 12:56:34, Rik van Riel wrote:
> On Thu, 2020-03-19 at 17:16 +0100, Michal Hocko wrote:
> > 
> > This is not the first time HAVE_MEMBLOCK_NODE_MAP has been
> > problematic.
> > I might be missing something but I really do not get why do we really
> > need it these days. As for !NUMA, I suspect we can make it generate
> > the
> > right thing when !NUMA.
> 
> We're working on a different fix now.
> 
> It looks like cma_declare_contiguous calls memblock_phys_alloc_range,
> which calls memblock_alloc_range_nid, which takes a NUMA node as one
> of its arguments.
> 
> Aslan is looking at simply adding a cma_declare_contiguous_nid, which
> also takes a NUMA node ID as an argument. At that point we can simply
> leave CMA free to allocate from anywhere in each NUMA node, which by
> default already happens from the top down.
> 
> That should be the nicer long term fix to this issue.

Yes, that sounds like a better solution. Not that I would be much
happier to have HAVE_MEMBLOCK_NODE_MAP off the table as well ;)
Ohh well, it will have to remain on my todo list for some longer.
-- 
Michal Hocko
SUSE Labs