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);