linux-kernel - Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Apr 2020 09:14:23 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Roman Gushchin <guro@...com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        kernel-team@...com, linux-kernel@...r.kernel.org,
        Rik van Riel <riel@...riel.com>,
        Andreas Schaufler <andreas.schaufler@....de>,
        Mike Kravetz <mike.kravetz@...cle.com>
Subject: Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages
 using cma

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@...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