隨著硬件能力的提升，系統(tǒng)內(nèi)存容量變得越來越大。尤其是在服務(wù)器上，過T級(jí)別的內(nèi)存容量也已經(jīng)不罕見了。

如此海量?jī)?nèi)存給內(nèi)核帶來了很多挑戰(zhàn)，其中之一就是page struct存放在哪里。

page struct的三種存放方式

在內(nèi)核中，我們將物理內(nèi)存按照頁大小進(jìn)行管理。這樣每個(gè)頁就對(duì)應(yīng)一個(gè)page struct作為這個(gè)頁的管理數(shù)據(jù)結(jié)構(gòu)。

隨著內(nèi)存容量的增加，相對(duì)應(yīng)的page struct也就增加。而這部分內(nèi)存和其他的內(nèi)存略有不同，因?yàn)檫@部分內(nèi)存不能給到頁分配器。也就是必須在系統(tǒng)能夠正常運(yùn)行起來之前就分配好。

在內(nèi)核中我們可以看到，為了應(yīng)對(duì)這樣的變化進(jìn)化出了幾個(gè)不同的版本。有幸的是，這部分內(nèi)容我們現(xiàn)在還能在代碼中直接看到，因?yàn)檫@個(gè)實(shí)現(xiàn)是通過內(nèi)核配置來區(qū)分的。我們通過查找_pfn_to_page的定義就能發(fā)現(xiàn)一下幾種memory model：

CONFIG_FLATMEM

CONFIG_SPARSEMEM

CONFIGSPARSEMEMVMEMMAP

接下來讓小編給各位看官一一道來。

1) FLATMEM

在這種情況下，宏_pfn_to_page的定義是：

#define__pfn_to_page(pfn)(mem_map+((pfn)-ARCH_PFN_OFFSET))

而這個(gè)mem_map的定義是

structpage*mem_map;

所以在這種情況下，page struct就是一個(gè)大數(shù)組，所有的人都按照自己的物理地址有序得挨著。

2) SPARSEMEM

雖然第一種方式非常簡(jiǎn)單直觀，但是有幾個(gè)非常大的缺點(diǎn)：

內(nèi)存如果有空洞，那么中間可能會(huì)有巨大的page struct空間浪費(fèi)

所有的page struct內(nèi)存都在一個(gè)NUMA節(jié)點(diǎn)上，會(huì)耗盡某一個(gè)節(jié)點(diǎn)內(nèi)存，甚至是分配失敗

且會(huì)產(chǎn)生夸NUMA訪問導(dǎo)致性能下降

所以第二種方式就是將內(nèi)存按照一定粒度，如128M，劃分了section，每個(gè)section中有個(gè)成員指定了對(duì)應(yīng)的page struct的存儲(chǔ)空間。

這樣就解決了上述的幾個(gè)問題：

如果有空洞，那么對(duì)應(yīng)的 page struct就不會(huì)占用空間

每個(gè)section對(duì)應(yīng)的page struct是屬于本地NUMA的

怎么樣，是不是覺得很完美。這一部分具體的實(shí)現(xiàn)可以可以看函數(shù)sparse_init()函數(shù)。

有了這個(gè)基礎(chǔ)知識(shí)，我們?cè)賮砜催@種情況下_pfn_to_page的定義：

#define __pfn_to_page(pfn) ({ unsigned long __pfn = (pfn); struct mem_section *__sec = __pfn_to_section(__pfn); __section_mem_map_addr(__sec) + __pfn; })

就是先找到pfn對(duì)應(yīng)的section，然后在section中保存的地址上翻譯出對(duì)應(yīng)pfn的page struct。

既然講到了這里，我們就要對(duì)sparsemem中重要的組成部分mem_section多說兩句。

先來一張mem_section的整體圖解：

這是一個(gè) NRSECTIONROOTS x SECTIONSPERROOT的二維數(shù)組。其中每一個(gè)成員就代表了我們剛才提到的128M內(nèi)存。

當(dāng)然最開始它不是這個(gè)樣子的。

其實(shí)最開始這個(gè)數(shù)組是一個(gè)靜態(tài)數(shù)組。很明顯這么做帶來的問題是這個(gè)數(shù)組定義太大太小都不合適。所以后來引進(jìn)了CONFIGSPARSEMEMEXTREME編譯選項(xiàng)，當(dāng)設(shè)置為y時(shí)，這個(gè)數(shù)組就變成了動(dòng)態(tài)的。

如果上面這個(gè)算作是空間上的限制的話，那么接下來就是一個(gè)時(shí)間上的限制了。

在系統(tǒng)初始化時(shí)，每個(gè)mem_section都要和相應(yīng)的內(nèi)存空間關(guān)聯(lián)。在老版本上，這個(gè)步驟通過對(duì)整個(gè)數(shù)組接待完成。原來的版本上問題不大，因?yàn)檎麄€(gè)數(shù)組的大小還沒有很大。但隨著內(nèi)存容量的增加，這個(gè)數(shù)值就變得對(duì)系統(tǒng)有影響了。如果系統(tǒng)上確實(shí)有這么多內(nèi)存，那么確實(shí)需要初始化也就忍了。但是在內(nèi)存較小的系統(tǒng)上，哪怕沒有這么多內(nèi)存，還是要挨個(gè)初始化，那就浪費(fèi)了太多的時(shí)間。

commit c4e1be9ec1130fff4d691cdc0e0f9d666009f9aeAuthor: Dave Hansen Date: Thu Jul 6 15:36:44 2017 -0700 mm, sparsemem: break out of loops earl

Dave在這個(gè)提交中增加了對(duì)系統(tǒng)最大存在內(nèi)存的跟蹤，來減少不必要的初始化時(shí)間。

瞧，內(nèi)核代碼一開始其實(shí)也沒有這么高大上不是。

3) SPARSEMEM_VMEMMAP

最后要講的，也是當(dāng)前x86系統(tǒng)默認(rèn)配置的內(nèi)存模型是SPARSEMEM_VMEMMAP。那為什么要引入這么一個(gè)新的模型呢？那自然是sparsemem依然有不足。

細(xì)心的朋友可能已經(jīng)注意到了，前兩種內(nèi)存模型在做pfn到page struct轉(zhuǎn)換是有著一些些的差異。為了看得清，我們把這兩個(gè)定義再拿過來對(duì)比一下：

先看看FLATMEM時(shí)的定義：

#define__pfn_to_page(pfn)(mem_map+((pfn)-ARCH_PFN_OFFSET))

再來看看使用SPASEMEM后的定義：

#define __pfn_to_page(pfn) ({ unsigned long __pfn = (pfn); struct mem_section *__sec = __pfn_to_section(__pfn); __section_mem_map_addr(__sec) + __pfn; })

更改后，需要先找到section，然后再?gòu)膕ection->memmap的內(nèi)容中換算出page的地址。

不僅計(jì)算的內(nèi)容多了，更重要的是還有一次訪問內(nèi)存的操作

可以想象，訪問內(nèi)存和單純計(jì)算之間的速度差異那是巨大的差距。

既然產(chǎn)生了這樣的問題，那有沒有辦法解決呢？其實(shí)說來簡(jiǎn)單，內(nèi)核開發(fā)者利用了我們常見的一個(gè)內(nèi)存單元來解決這個(gè)問題。

頁表

是不是很簡(jiǎn)單粗暴？如果我們能夠通過某種方式將page struct線性映射到頁表，這樣我們不就能又通過簡(jiǎn)單的計(jì)算來換算物理地址和page struct了么？

內(nèi)核開發(fā)者就是這么做的，我們先來看一眼最后那簡(jiǎn)潔的代碼：

#define__pfn_to_page(pfn)(vmemmap+(pfn))

經(jīng)過內(nèi)核開發(fā)這的努力，物理地址到page struct的轉(zhuǎn)換又變成如此的簡(jiǎn)潔。不需要訪問內(nèi)存，所以速度的問題得到了解決。

但是天下沒有免費(fèi)的午餐，世界哪有這么美好，魚和熊掌可以兼得的情況或許只有在夢(mèng)境之中。為了達(dá)到如此簡(jiǎn)潔的轉(zhuǎn)化，我們是要付出代價(jià)的。為了實(shí)現(xiàn)速度上的提升，我們付出了空間的代價(jià)。

至此引出了計(jì)算機(jī)界一個(gè)經(jīng)典的話題：

時(shí)間和空間的轉(zhuǎn)換

話不多說，也不矯情了，我們來看看內(nèi)核中實(shí)現(xiàn)的流程。

既然是利用了頁表進(jìn)行轉(zhuǎn)換，那么自然是要構(gòu)建頁表在做這樣的映射。這個(gè)步驟主要由函數(shù)vmemmap_populate()來完成，其中還區(qū)分了有沒有大頁的情況。我們以普通頁的映射為例，看看這個(gè)實(shí)現(xiàn)。

int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end, int node){ unsigned long addr = start; pgd_t *pgd; p4d_t *p4d; pud_t *pud; pmd_t *pmd; pte_t *pte; for (; addr < end; addr += PAGE_SIZE) { pgd = vmemmap_pgd_populate(addr, node); if (!pgd) return -ENOMEM; p4d = vmemmap_p4d_populate(pgd, addr, node); if (!p4d) return -ENOMEM; pud = vmemmap_pud_populate(p4d, addr, node); if (!pud) return -ENOMEM; pmd = vmemmap_pmd_populate(pud, addr, node); if (!pmd) return -ENOMEM; pte = vmemmap_pte_populate(pmd, addr, node); if (!pte) return -ENOMEM; vmemmap_verify(pte, node, addr, addr + PAGE_SIZE); } return 0;}

內(nèi)核代碼的優(yōu)美之處就在于，你可能不一定看懂了所有細(xì)節(jié)，但是從優(yōu)美的結(jié)構(gòu)上能猜到究竟做了些什么。上面這段代碼的工作就是對(duì)每一個(gè)頁，按照層級(jí)去填充頁表內(nèi)容。其中具體的細(xì)節(jié)就不在這里展開了，相信有興趣的同學(xué)會(huì)自行去探索。

那這么做的代價(jià)究竟是多少呢？

以x86為例，每個(gè)section是128M，那么每個(gè)section的page struct正好是2M，也就是一個(gè)大頁。

(128M / 4K) * 64 = (128 * (1 < 20) / (1 < 12)) * 64 = 2M

假如使用大頁做頁表映射，那么每64G才用掉一個(gè)4K頁表做映射。

128M * 512 = 64G

所以在使用大頁映射的情況下，這個(gè)損耗的級(jí)別在百萬分之一。還是能夠容忍的。

好了，我們終于沿著內(nèi)核發(fā)展的歷史重走了一遍安放page struct之路。相信大家在這一路上領(lǐng)略了代碼演進(jìn)的樂趣，也會(huì)對(duì)以后自己代碼的設(shè)計(jì)有了更深的思考。