Gigantic巨页与CMA的完全结合

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区域的:

Gigantic巨页与CMA的完全结合_第1张图片

释放的时候则是也先看有无这种CMA:

Gigantic巨页与CMA的完全结合_第2张图片

如果这种CMA根本不存在,还是会走到老的代码路径:

alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);


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

(END)

Linux阅码场原创精华文章汇总

更多精彩,尽在"Linux阅码场",扫描下方二维码关注

别忘了点个在看哦

你可能感兴趣的:(Gigantic巨页与CMA的完全结合)