Facebook的Roman Gushcin發(fā)送的這個patch把Gigantic巨頁（SIZE：1GB）與CMA進行了一個完美的結(jié)合：

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

CMA有利于在開機的時候就預(yù)留一大片內(nèi)存，但是這片內(nèi)存如果不被cma_alloc()申請走，則可被movable的頁面復(fù)用，并不會造成直接的浪費。

而Linux的Gigantic hugepage則要求能夠在運行時通過

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

這樣的方法能申請一定數(shù)量的1GB Gigantic巨頁，由于運行時內(nèi)存碎片化掉了，這種1GB的Gigantic巨頁很可能申請不到。通過CMA的方法，則可以讓這種申請在運行時成功。

所以整個故事是：

CMA比如預(yù)留4GB內(nèi)存專門供給hugetlb，如果沒有人去進行Gigantic巨頁設(shè)置，則這個4GB就平時被applications的movable頁面使用掉了。

如果有人通過

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

拿走1GB，則這1GB就被從CMA拿走，剩下的3GB仍然可以被movable page使用。

用戶可以在開機的時候通過hugetlb_cma bootargs來設(shè)置CMA的大小，如果是NUMA架構(gòu)的(假設(shè)有4個NUMA NODE)，設(shè)置hugetlb_cma=4GB大小，則每個NUMA節(jié)點會分配到1GB大小的CMA。

從代碼看起來，現(xiàn)在申請1GB的gigantic頁面的時候，如果有這種CMA區(qū)域，是先走CMA區(qū)域的：

釋放的時候則是也先看有無這種CMA：

如果這種CMA根本不存在，還是會走到老的代碼路徑：

alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);

和

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