Facebook的Roman Gushcin发送的这个patch把Gigantic巨页（SIZE：1GB）与CMA进行了一个完美的结合：
https://lkml.org/lkml/2020/3/9/1135
CMA有利于在开机的时候就预留一大片内存，但是这片内存如果不被cma_alloc()申请走，则可被movable的页面复用，并不会造成直接的浪费。
而Linux的Gigantic hugepage则要求能够在运行时通过
代码语言：javascript复制echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages这样的方法能申请一定数量的1GB Gigantic巨页，由于运行时内存碎片化掉了，这种1GB的Gigantic巨页很可能申请不到。通过CMA的方法，则可以让这种申请在运行时成功。
所以整个故事是：
CMA比如预留4GB内存专门供给hugetlb，如果没有人去进行Gigantic巨页设置，则这个4GB就平时被applications的movable页面使用掉了。
如果有人通过
代码语言：javascript复制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根本不存在，还是会走到老的代码路径：
代码语言：javascript复制alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);和
代码语言：javascript复制free_contig_range(page_to_pfn(page), 1 << order);
