1
0
Fork 0
alistair23-linux/arch/arm64
Roman Gushchin cf11e85fc0 mm: hugetlb: optionally allocate gigantic hugepages using cma
Commit 944d9fec8d ("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 1GB
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@fb.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Andreas Schaufler <andreas.schaufler@gmx.de>
Acked-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Michal Hocko <mhocko@kernel.org>
Cc: Aslan Bakirov <aslan@fb.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Joonsoo Kim <js1304@gmail.com>
Link: http://lkml.kernel.org/r/20200407163840.92263-3-guro@fb.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-10 15:36:21 -07:00
..
boot ARM: devicetree updates for v5.7 2020-04-03 15:22:05 -07:00
configs ARM: defconfig updates 2020-04-03 15:15:10 -07:00
crypto SPDX patches for 5.7-rc1. 2020-04-03 13:12:26 -07:00
include arm64 fixes: 2020-04-09 11:04:16 -07:00
kernel arm64 fixes: 2020-04-09 11:04:16 -07:00
kvm virtio: fixes, vdpa 2020-04-08 10:51:53 -07:00
lib arm64: fix spelling mistake "ca not" -> "cannot" 2020-03-17 18:22:40 +00:00
mm mm: hugetlb: optionally allocate gigantic hugepages using cma 2020-04-10 15:36:21 -07:00
net arm64: bpf: optimize modulo operation 2019-09-03 15:44:40 +02:00
xen arm64: xen: Use modern annotations for assembly functions 2020-01-09 16:09:42 +00:00
Kbuild arm64: add arch/arm64/Kbuild 2019-08-21 18:47:15 +01:00
Kconfig arm64 fixes: 2020-04-09 11:04:16 -07:00
Kconfig.debug arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature 2020-04-01 21:44:43 +01:00
Kconfig.platforms ARM: SoC updates 2020-04-03 15:02:35 -07:00
Makefile arm64: Always force a branch protection mode when the compiler has one 2020-04-01 21:23:40 +01:00