原创 宋宝华 Linux阅码场 6月27日 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)