linux-kernel - Re: [PATCH v5 2/2] 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-next>] [day] [month] [year] [list]

Message-ID: <20200407181546.GV18914@dhcp22.suse.cz>
Date:   Tue, 7 Apr 2020 20:15:46 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Roman Gushchin <guro@...com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Aslan Bakirov <aslan@...com>, linux-mm@...ck.org,
        kernel-team@...com, linux-kernel@...r.kernel.org,
        Rik van Riel <riel@...riel.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Andreas Schaufler <andreas.schaufler@....de>,
        Randy Dunlap <rdunlap@...radead.org>,
        Joonsoo Kim <js1304@...il.com>
Subject: Re: [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic
 hugepages using cma

On Tue 07-04-20 09:38:40, Roman Gushchin wrote:
> Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at
> runtime") has added the run-time allocation of gigantic pages.  However it
> actually works only at early stages of the system loading, when the
> majority of memory is free.  After some time the memory gets fragmented by
> non-movable pages, so the chances to find a contiguous 1 GB block are
> getting close to zero.  Even dropping caches manually doesn't help a lot.
> 
> 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.
> 
> The patch contains clean-ups and fixes proposed and implemented by
> Aslan Bakirov and Randy Dunlap. It also contains ideas and suggestions
> proposed by Rik van Riel, Michal Hocko and Mike Kravetz. Thanks!
> 
> Signed-off-by: Roman Gushchin <guro@...com>
> Tested-by: Andreas Schaufler <andreas.schaufler@....de>
> Acked-by: Mike Kravetz <mike.kravetz@...cle.com>
> Acked-by: Michal Hocko <mhocko@...nel.org>
> Cc: Aslan Bakirov <aslan@...com>
> Cc: Randy Dunlap <rdunlap@...radead.org>
> Cc: Rik van Riel <riel@...riel.com>
> Cc: Joonsoo Kim <js1304@...il.com>

Thanks a lot for addressing my review feedback!
-- 
Michal Hocko
SUSE Labs