內(nèi)容簡介

介紹以一種創(chuàng)新的方式優(yōu)化HugeTLB對應(yīng)的struct page內(nèi)存占用。

相信大家對HugeTLB在虛擬化及DPDK等場景應(yīng)用并不陌生，在動不動就上百GB的服務(wù)器上，輕輕松松預(yù)留上百GB HugeTLB。相信不少云廠商也注意到HugeTLB的內(nèi)存管理上存在一定的問題。既然有問題，為何upstream上遲遲看不到相關(guān)的優(yōu)化patch呢？

答案很簡單：問題棘手。

Linux在內(nèi)存管理方面已經(jīng)發(fā)展了十幾年，即使某些機(jī)制不夠優(yōu)秀，想大改也不是簡單的事情。內(nèi)存管理貫徹整個(gè)Linux內(nèi)核，與眾多子系統(tǒng)交互。究竟Linux在HugeTLB的管理上存在什么問題呢？

如何管理物理內(nèi)存

現(xiàn)在Linux Kernel主要以頁為單位管理內(nèi)存，而頁的大小默認(rèn)4 KB。為了方便管理物理內(nèi)存，Linux為每個(gè)頁分配一個(gè)metadata結(jié)構(gòu)體，即struct page結(jié)構(gòu)，其大小通常64 Bytes。struct page可以簡單理解成一個(gè)數(shù)組，數(shù)組的index就是PFN（物理頁幀號）。我稱這段區(qū)域vmemmap。

4KB頁我們稱之為小頁，與之相反的是大頁。在x86-64平臺，硬件支持2 MB和1 GB大頁。Linux為了方便用戶使用大頁，提供2種不同的機(jī)制，分別是THP (Transparent Huge Page)和 HugeTLB。HugeTLB經(jīng)常出現(xiàn)在我們的工程實(shí)踐中，HugeTLB為我們?yōu)槲覀儙聿诲e(cuò)的性能提升。

但是也有一朵烏云常伴其身。雖然2 MB的HugeTLB page理論上也只需要1個(gè)struct page結(jié)構(gòu)，但是，在系統(tǒng)啟動之初，所有的物理內(nèi)存均以4 KB為單位分配struct page結(jié)構(gòu)。因此每個(gè) HugeTLB page對應(yīng) 512個(gè)struct page結(jié)構(gòu)，占用內(nèi)存32 KB（折合8個(gè)4 KB小頁）。

可能你會好奇這能有多少內(nèi)存。針對嵌入式系統(tǒng)，確實(shí)不值一提。但是別忘了，我們有動不動就2 TB物理內(nèi)存的服務(wù)器。

現(xiàn)在我們可以簡單的算一筆賬了。假設(shè)在一臺1 TB的服務(wù)器上，我們分配1 TB的2 MB大頁（理想情況下），那么struct page本身占用的內(nèi)存是多少呢？沒錯(cuò)，是16 GB。如果有上千臺，上萬臺，甚至上十萬臺機(jī)器呢？如果我們能夠優(yōu)化掉16 GB的內(nèi)存浪費(fèi)或者盡可能的降低struct page的內(nèi)存占用，我們將會降低服務(wù)器平臺成本。我們的目標(biāo)就是盡量驅(qū)散這朵烏云。

面臨的挑戰(zhàn)

我們試圖找到一種最簡單并且對其他模塊影響最小的設(shè)計(jì)方案，在這過程中我們遇到不少挑戰(zhàn)。

1. 不需要用戶適配

理想情況下，我們的優(yōu)化不應(yīng)該涉及用戶態(tài)的適配。如果引入一種全新的內(nèi)存管理方式，所有的用戶需要適配。我們的目標(biāo)是開箱即用。

2.不影響內(nèi)核其他模塊功能

在確定不需要用戶適配的前提下，我們預(yù)期所有的代碼修改只會集中于內(nèi)核。我們知道內(nèi)存管理的幾乎全是圍繞著struct page管理，各個(gè)不同子系統(tǒng)的模塊幾乎都和struct page息息相關(guān)。暴力的釋放所有的HugeTLB相關(guān)的struct page結(jié)構(gòu)體是不合適的，否則將會影響內(nèi)核各個(gè)內(nèi)存子系統(tǒng)。既要釋放，但又不能釋放。這恐怕是最棘手和矛盾的問題了。

3.代碼修改最小化

代碼量間接的決定了bug的數(shù)量。內(nèi)存管理子系統(tǒng)修改代碼過多，勢必影響內(nèi)核的穩(wěn)定性。我們既要實(shí)現(xiàn)功能，又要以最少的代碼量實(shí)現(xiàn)。這不但可以降低bug出現(xiàn)的概率，同時(shí)也易于維護(hù)和理解。

初次探索

一種最簡單直接的方法浮出水面。那就是動態(tài)分配和釋放struct page。

HugeTLB的使用方法一般是先預(yù)留后使用。并且struct page只會被內(nèi)核代碼訪問，我們傾向內(nèi)核訪問struct page的概率較低。因此我們第一次提出的方案是壓縮解壓縮的方法。

我們知道HugeTLB對應(yīng)的512個(gè)struct page對應(yīng)的信息可以壓縮到 100個(gè)字節(jié)左右，因此我們可以為每個(gè)HugeTLB準(zhǔn)備一個(gè)全新的metadata結(jié)構(gòu)體，然后將所有的信息壓縮到新的metadata結(jié)構(gòu)體。并且將struct page區(qū)域?qū)?yīng)的頁表的present清除，然后就可以將其對應(yīng)的物理頁釋放。是不是和zram機(jī)制如出一轍？

內(nèi)核在下次訪問HugeTLB的struct page的時(shí)候觸發(fā)page fault，在fault里面分配struct page需要的物理頁，并解壓縮（從新的metadata結(jié)構(gòu)體恢復(fù)數(shù)據(jù)）。

當(dāng)內(nèi)核使用完成后，會執(zhí)行put_page操作。我們在put_page里面做壓縮操作，并釋放vmemmap對應(yīng)的物理頁。思路很直接，但是這里面存在很多挑戰(zhàn)。

1. page fault里面無法分配怎么辦（例如：OOM）？

2. page fault可能發(fā)生在任何上下文，用GFP_NOWAIT分配內(nèi)存？這只會加重第一個(gè)問題。

3. 如果某一持有A鎖的路徑觸發(fā)page fault，page fault里面也嘗試持有A鎖怎么樣？只會死鎖。所以page fault的操作需要格外小心。

4. 壓縮和解壓縮操作如何做到原子？或者說壓縮操作如何和解壓縮操作互斥同步？

5. 每次put_page都需要壓縮操作，性能影響如何？

6. 如果某些內(nèi)核路徑并沒有g(shù)et操作訪問struct page（自然也不會put），壓縮的時(shí)機(jī)會是什么時(shí)候？

我們列出了很多問題，但就第一個(gè)問題來說就很難解決。這不得不讓我們放棄了這個(gè)想法。我們只能另尋他路。換個(gè)思路或許柳暗花明。

另辟蹊徑

俗話說“知己知彼百戰(zhàn)不殆”。我們先詳細(xì)了解struct page是如何組織和管理的，清楚每一處細(xì)節(jié)，才可能運(yùn)籌帷幄。

我們上面提到每個(gè)HugeTLB page對應(yīng)512個(gè)struct page結(jié)構(gòu)，而HugeTLB只使用前3個(gè)struct page結(jié)構(gòu)存儲大頁相關(guān)的metadata。那么其余509個(gè)struct page是否完全沒有意義呢？如果沒有意義我們是不是就可以直接釋放這些內(nèi)存。

然而事情并沒有那么簡單。這些509個(gè)struct page會存儲第一個(gè)struct page的地址（struct page中compound_head字段）。如果第一個(gè)struct page稱之為head page的話，那么其余的struct page都是tail page。在Linux內(nèi)核的內(nèi)存管理的代碼中充斥著大量的代碼，這些代碼都可能試圖從tail page獲取head page。所以我們并不能單純的釋放這些內(nèi)存。

上圖展示的3個(gè)struct page的結(jié)構(gòu)體示意圖（第3個(gè)tail page至第511個(gè)struct page結(jié)構(gòu)體使用的位域同圖中2nd tail page）。我們可以總結(jié)出以下特點(diǎn)：

1. struct page結(jié)構(gòu)體的大小在大多數(shù)情況下是64字節(jié)，因此每個(gè)4 KB的物理頁可以存儲整數(shù)個(gè)數(shù)的struct page結(jié)構(gòu)體。

2. 第2個(gè)tail page至第511個(gè)struct page結(jié)構(gòu)體的內(nèi)容完全一樣。

3. 內(nèi)存管理的代碼中只會修改head page，1st tail page的2nd tail page的結(jié)構(gòu)體，其余的tail page結(jié)構(gòu)體內(nèi)存不會修改。

4. 每個(gè)2MB HugeTLB page對應(yīng)512個(gè)struct page，內(nèi)存占用8個(gè)頁（4KB * 8）。

5. struct page所在的vmemmap區(qū)域和內(nèi)核的線性映射地址不重合。

基于以上特點(diǎn)，我們可以提出全新的解決方案：共享映射，將HugeTLB對應(yīng)的后7個(gè)頁的vmemmap虛擬地址映射到第1個(gè)vmemmap頁對應(yīng)的物理頁幀。第1-2點(diǎn)是共享映射方案的基礎(chǔ)。基于第3點(diǎn)我們可以將這7個(gè)物理頁釋放，交給buddy系統(tǒng)管理。而第5點(diǎn)是buddy能夠管理這塊物理內(nèi)存的基礎(chǔ)。內(nèi)核通過線性地址訪問物理內(nèi)存，所以這個(gè)地址不能和vmemmap共用。其原理如下圖所示。基于第3點(diǎn)，我們將共享映射屬性改成只讀，防止出現(xiàn)異常情況。

內(nèi)存收益

經(jīng)過上面的優(yōu)化，我們成功的降低了服務(wù)器平臺成本，并且收益不錯(cuò)。針對1 GB和2 MB不同size的HugeTLB page，內(nèi)存收益也同樣不同。簡單歸納表格如下：

如果使用1 GB HugeTLB，內(nèi)存收益約為HugeTLB總量的1.6%。如果使用2 MB HugeTLB，內(nèi)存收益約為HugeTLB總量的1.4%。

因此，在我們1臺1 TB內(nèi)存的服務(wù)器上，如果使用1 GB大頁，struct page內(nèi)存占用優(yōu)化提升接近100%。如果使用2MB大頁，struct page內(nèi)存占用優(yōu)化提升約87.5%。

性能分析

我們知道vmemmap區(qū)域映射的單位是2 MB。但是我們需要以4 KB頁為單位修改頁表，因此必須修改vmemmap區(qū)域?yàn)樾№撚成洹＿@相當(dāng)于在內(nèi)核訪問vmemmap區(qū)域時(shí)，MMU會多訪問一級 PTE 頁表。但是有TLB的存在，所以查找的性能損失并不大。

但是我們同樣也有性能提升的地方，由于我們減少了vmemmap對應(yīng)的物理頁。理論上來說，我們更容易命中cache。實(shí)際上也確實(shí)這樣，經(jīng)過upstream的測試數(shù)據(jù)顯示，對HugeTLB page進(jìn)行g(shù)et_user_page操作性能可以提升接近 4 倍。

開源計(jì)劃

為了降低代碼review的難度，我們決定將全部patch拆分成3筆patchset。目前第一步基礎(chǔ)功能已經(jīng)合入linux-next分支（代碼參考:[v23,0/9] Free some vmemmap pages of HugeTLB page，點(diǎn)擊文末左下角閱讀原文可達(dá)），不出意外的話，預(yù)計(jì)Linux 5.14會和大家見面。

后續(xù)我們繼續(xù)放出接下來的patchset。那么接下來有哪些功能呢？

首先第一個(gè)功能是釋放7個(gè)page。什么？這不是上面已經(jīng)說的功能嗎？是的，但是我們的第一個(gè)patchset只釋放了6個(gè)page。所以在上面的patchset中，我們建立的映射關(guān)系其實(shí)如下圖所示。這才是最簡單的情況。因?yàn)槲覀僪ead page和tail page的結(jié)構(gòu)體內(nèi)容其實(shí)是不一樣的，如果要實(shí)現(xiàn)上面的圖的映射關(guān)系，必然要有一些trick才行。另一組patchset是拆分vmemmap頁表。第一組patchset的實(shí)現(xiàn)并不包含拆分vmemmap頁表，而是系統(tǒng)啟動時(shí)使vmemmap頁表以PTE方式建立映射，而非PMD映射。

原文標(biāo)題：圍繞HugeTLB的極致優(yōu)化

文章出處：【微信公眾號：Linux閱碼場】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq