聊聊圍繞HugeTLB的創(chuàng)新優(yōu)化

作者： 宋牧春 2021-06-11 06:54:35
云計(jì)算
虛擬化 相信大家對(duì)HugeTLB在虛擬化及DPDK等場(chǎng)景應(yīng)用并不陌生，在動(dòng)不動(dòng)就上百GB的服務(wù)器上，輕輕松松預(yù)留上百GB HugeTLB。相信不少云廠商也注意到HugeTLB的內(nèi)存管理上存在一定的問題。

創(chuàng)新互聯(lián)是專業(yè)的云浮網(wǎng)站建設(shè)公司，云浮接單;提供成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行云浮網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

內(nèi)容簡(jiǎn)介

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

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

答案很簡(jiǎn)單：?jiǎn)栴}棘手。

Linux在內(nèi)存管理方面已經(jīng)發(fā)展了十幾年，即使某些機(jī)制不夠優(yōu)秀，想大改也不是簡(jiǎn)單的事情。內(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可以簡(jiǎn)單理解成一個(gè)數(shù)組，數(shù)組的index就是PFN(物理頁幀號(hào))。我稱這段區(qū)域vmemmap。

圖片4KB頁我們稱之為小頁，與之相反的是大頁。在x86-64平臺(tái)，硬件支持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)啟動(dòng)之初，所有的物理內(nèi)存均以4 KB為單位分配struct page結(jié)構(gòu)。因此每個(gè) HugeTLB page對(duì)應(yīng) 512個(gè)struct page結(jié)構(gòu)，占用內(nèi)存32 KB(折合8個(gè)4 KB小頁)。

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

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

面臨的挑戰(zhàn)

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

1. 不需要用戶適配

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

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

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

3. 代碼修改最小化

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

初次探索

圖片

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

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

我們知道HugeTLB對(duì)應(yīng)的512個(gè)struct page對(duì)應(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清除，然后就可以將其對(duì)應(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)核使用完成后，會(huì)執(zhí)行put_page操作。我們?cè)趐ut_page里面做壓縮操作，并釋放vmemmap對(duì)應(yīng)的物理頁。思路很直接，但是這里面存在很多挑戰(zhàn)。

1. page fault里面無法分配怎么辦(例如：OOM)?

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

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

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

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

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

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

另辟蹊徑

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

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

然而事情并沒有那么簡(jiǎn)單。這些509個(gè)struct page會(huì)存儲(chǔ)第一個(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的物理頁可以存儲(chǔ)整數(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)存管理的代碼中只會(huì)修改head page，1st tail page的2nd tail page的結(jié)構(gòu)體，其余的tail page結(jié)構(gòu)體內(nèi)存不會(huì)修改。

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

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

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

內(nèi)存收益

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

Total Size of HugeTLB Page	HugeTLB Type	Memory Gain
512 GB	1 GB	~8 GB
1024 GB	1 GB	~16 GB
512 GB	2 MB	~7 GB
1024 GB	2 MB	~14 GB

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

因此，在我們1臺(tái)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會(huì)多訪問一級(jí) PTE 頁表。但是有TLB的存在，所以查找的性能損失并不大。

但是我們同樣也有性能提升的地方，由于我們減少了vmemmap對(duì)應(yīng)的物理頁。理論上來說，我們更容易命中cache。實(shí)際上也確實(shí)這樣，經(jīng)過upstream的測(cè)試數(shù)據(jù)顯示，對(duì)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會(huì)和大家見面。

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

首先第一個(gè)功能是釋放7個(gè)page。什么?這不是上面已經(jīng)說的功能嗎?是的，但是我們的第一個(gè)patchset只釋放了6個(gè)page。所以在上面的patchset中，我們建立的映射關(guān)系其實(shí)如下圖所示。這才是最簡(jiǎn)單的情況。因?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)啟動(dòng)時(shí)使vmemmap頁表以PTE方式建立映射，而非PMD映射。

作者簡(jiǎn)介

宋牧春，字節(jié)跳動(dòng)系統(tǒng)技術(shù)與工程團(tuán)隊(duì)，Linux內(nèi)核工程師。

本文轉(zhuǎn)載自微信公眾號(hào)「Linux閱碼場(chǎng)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Linux閱碼場(chǎng)公眾號(hào)。

網(wǎng)站名稱：聊聊圍繞HugeTLB的創(chuàng)新優(yōu)化
分享URL：http://www.dlmjj.cn/article/dpspcch.html