Gigantic巨页与CMA的完全结合

Facebook的Roman Gushcin发送的这个patch把Gigantic巨页（SIZE：1GB）与CMA进行了一个完美的结合：

https://lkml.org/lkml/2020/3/9/1135

CMA有利于在开机的时候就预留一大片内存，但是这片内存如果不被cma_alloc()申请走，则可被movable的页面复用，并不会造成直接的浪费。

而Linux的Gigantic hugepage则要求能够在运行时通过

echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

这样的方法能申请一定数量的1GB Gigantic巨页，由于运行时内存碎片化掉了，这种1GB的Gigantic巨页很可能申请不到。通过CMA的方法，则可以让这种申请在运行时成功。

所以整个故事是：

CMA比如预留4GB内存专门供给hugetlb，如果没有人去进行Gigantic巨页设置，则这个4GB就平时被applications的movable页面使用掉了。

如果有人通过

echo 1 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

拿走1GB，则这1GB就被从CMA拿走，剩下的3GB仍然可以被movable page使用。

用户可以在开机的时候通过hugetlb_cma bootargs来设置CMA的大小，如果是NUMA架构的(假设有4个NUMA NODE)，设置hugetlb_cma=4GB大小，则每个NUMA节点会分配到1GB大小的CMA。

从代码看起来，现在申请1GB的gigantic页面的时候，如果有这种CMA区域，是先走CMA区域的：

释放的时候则是也先看有无这种CMA：

如果这种CMA根本不存在，还是会走到老的代码路径：

alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);

和

free_contig_range(page_to_pfn(page), 1 << order);

(END)