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

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

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

而Linux的Gigantic hugepage則要求能夠在運(yùn)行時(shí)通過

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

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

所以整個(gè)故事是：

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

如果有人通過

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

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

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

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

釋放的時(shí)候則是也先看有無(wú)這種CMA：

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

alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);

和

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