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, 2 Apr 2020 09:14:23 +0200
From:   Michal Hocko <mhocko@kernel.org>
To:     Roman Gushchin <guro@fb.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        kernel-team@fb.com, linux-kernel@vger.kernel.org,
        Rik van Riel <riel@surriel.com>,
        Andreas Schaufler <andreas.schaufler@gmx.de>,
        Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages
 using cma
Message-ID: <20200402071423.GE22681@dhcp22.suse.cz>
References: <20200311220920.2487528-1-guro@fb.com>
 <20200401192553.7f437f150203a5fa044a1f75@linux-foundation.org>
 <20200402024406.GA69473@carbon.DHCP.thefacebook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200402024406.GA69473@carbon.DHCP.thefacebook.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed 01-04-20 19:44:06, Roman Gushchin wrote:
> On Wed, Apr 01, 2020 at 07:25:53PM -0700, Andrew Morton wrote:
> > On Wed, 11 Mar 2020 15:09:20 -0700 Roman Gushchin <guro@fb.com> wrote:
> > 
> > > At large scale rebooting servers in order to allocate gigantic hugepages
> > > is quite expensive and complex. At the same time keeping some constant
> > > percentage of memory in reserved hugepages even if the workload isn't
> > > using it is a big waste: not all workloads can benefit from using 1 GB
> > > pages.
> > > 
> > > The following solution can solve the problem:
> > > 1) On boot time a dedicated cma area* is reserved. The size is passed
> > >    as a kernel argument.
> > > 2) Run-time allocations of gigantic hugepages are performed using the
> > >    cma allocator and the dedicated cma area
> > > 
> > > In this case gigantic hugepages can be allocated successfully with a
> > > high probability, however the memory isn't completely wasted if nobody
> > > is using 1GB hugepages: it can be used for pagecache, anon memory,
> > > THPs, etc.
> > > 
> > > * On a multi-node machine a per-node cma area is allocated on each node.
> > >   Following gigantic hugetlb allocation are using the first available
> > >   numa node if the mask isn't specified by a user.
> > > 
> > > Usage:
> > > 1) configure the kernel to allocate a cma area for hugetlb allocations:
> > >    pass hugetlb_cma=10G as a kernel argument
> > > 
> > > 2) allocate hugetlb pages as usual, e.g.
> > >    echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> > > 
> > > If the option isn't enabled or the allocation of the cma area failed,
> > > the current behavior of the system is preserved.
> > > 
> > > x86 and arm-64 are covered by this patch, other architectures can be
> > > trivially added later.
> > 
> > Lots of review input on v2, but then everyone went quiet ;)
> > 
> > Has everything been addressed?
> 
> I hope so. There is a nice cleanup from Aslan, which can be merged in or
> treated as a separate patch.

With the follow up patche I didn't have any objections. I would prefer
having hugetlb parts folded into the original patch to make the review
easier though. Then I can have a look again. If those patches are going
to be as they are now then no problem with me.
-- 
Michal Hocko
SUSE Labs