深度解析Linux的內(nèi)存管理體系

一、內(nèi)存管理概覽

內(nèi)存是計(jì)算機(jī)最重要的資源之一，內(nèi)存管理是操作系統(tǒng)最重要的任務(wù)之一。內(nèi)存管理并不是簡(jiǎn)單地管理一下內(nèi)存而已，它還直接影響著操作系統(tǒng)的風(fēng)格以及用戶空間編程的模式。可以說內(nèi)存管理的方式是一個(gè)系統(tǒng)刻入DNA的秉性。既然內(nèi)存管理那么重要，那么今天我們就來全面系統(tǒng)地講一講Linux內(nèi)存管理。

1.1 內(nèi)存管理的意義

外存是程序存儲(chǔ)的地方，內(nèi)存是進(jìn)程運(yùn)行的地方。外存相當(dāng)于是軍營，內(nèi)存相當(dāng)于是戰(zhàn)場(chǎng)。選擇一個(gè)良好的戰(zhàn)場(chǎng)才有利于軍隊(duì)打勝仗，實(shí)現(xiàn)一個(gè)完善的內(nèi)存管理機(jī)制才能讓進(jìn)程多快好省地運(yùn)行。如何更好地實(shí)現(xiàn)內(nèi)存管理一直是操作系統(tǒng)發(fā)展的一大主題。在此過程中內(nèi)存管理的基本模式也經(jīng)歷了好幾代的發(fā)展，下面我們就來看一下。

1.2 原始內(nèi)存管理

最初的時(shí)候，內(nèi)存管理是十分的簡(jiǎn)陋，大家都運(yùn)行在物理內(nèi)存上，內(nèi)核和進(jìn)程運(yùn)行在一個(gè)空間中，內(nèi)存分配算法有首次適應(yīng)算法(FirstFit)、最佳適應(yīng)算法(BestFit)、最差適應(yīng)算法(WorstFit)等。顯然，這樣的內(nèi)存管理方式問題是很明顯的。內(nèi)核與進(jìn)程之間沒有做隔離，進(jìn)程可以隨意訪問(干擾、竊取)內(nèi)核的數(shù)據(jù)。而且進(jìn)程和內(nèi)核沒有權(quán)限的區(qū)分，進(jìn)程可以隨意做一些敏感操作。還有一個(gè)問題就是當(dāng)時(shí)的物理內(nèi)存非常少，能同時(shí)運(yùn)行的進(jìn)程比較少，運(yùn)行進(jìn)程的吞吐量比較少。

1.3 分段內(nèi)存管理

于是第二代內(nèi)存管理方式，分段內(nèi)存管理誕生了。分段內(nèi)存管理需要硬件的支持和軟件的配合。在分段內(nèi)存中，軟件可以把物理內(nèi)存分成一個(gè)一個(gè)的段，每個(gè)段都有段基址和段限長，還有段類型和段權(quán)限。段基址和段限長確定一個(gè)段的范圍，可以防止內(nèi)存訪問越界。段與段之間也可以互相訪問，但是不能隨便訪問，有一定的規(guī)則限制。段類型分為代碼段和數(shù)據(jù)段，正好對(duì)應(yīng)程序的代碼和數(shù)據(jù)，代碼段是只讀和可執(zhí)行的，數(shù)據(jù)段有只讀數(shù)據(jù)段和讀寫數(shù)據(jù)段。代碼段是不可寫的，只讀數(shù)據(jù)段也是不可寫，數(shù)據(jù)段是不可執(zhí)行的，這樣又增加了一層安全性。段權(quán)限分為有特權(quán)(內(nèi)核權(quán)限)和無特權(quán)(用戶權(quán)限)，內(nèi)核的代碼段和數(shù)據(jù)段都設(shè)置為特權(quán)段，進(jìn)程的代碼段和數(shù)據(jù)段都設(shè)置為用戶段，這樣進(jìn)程就不能隨意訪問內(nèi)核了。當(dāng)CPU執(zhí)行特權(quán)段代碼的時(shí)候會(huì)把自己設(shè)置為特權(quán)模式，此時(shí)CPU可以執(zhí)行所以的指令。當(dāng)CPU執(zhí)行用戶段代碼的時(shí)候會(huì)把自己設(shè)置為用戶模式，此時(shí)CPU只能執(zhí)行普通指令，不能執(zhí)行敏感指令。

至此，分段內(nèi)存管理完美解決了原始內(nèi)存管理存在的大部分問題：進(jìn)程與內(nèi)核之間的隔離實(shí)現(xiàn)了，進(jìn)程不能隨意訪問內(nèi)核了；CPU特權(quán)級(jí)實(shí)現(xiàn)了，進(jìn)程無法再執(zhí)行敏感指令了；內(nèi)存訪問的安全性提高了，越界訪問和野指針問題得到了一定程度的遏制。但是分段內(nèi)存管理還有一個(gè)嚴(yán)重的問題沒有解決，那就是當(dāng)時(shí)的物理內(nèi)存非常少的問題。為此當(dāng)時(shí)想的辦法是用軟件方法來解決，而且是進(jìn)程自己解決。程序員在編寫程序的時(shí)候就要想好，把程序分成幾個(gè)模塊，關(guān)聯(lián)不大的模塊，它們占用相同的物理地址。然后再編寫一個(gè)overlay manager，在程序運(yùn)行的時(shí)候，動(dòng)態(tài)地加載即將會(huì)運(yùn)行的模塊，覆蓋掉暫時(shí)不用的模塊。這樣一個(gè)程序占用較少的物理內(nèi)存，也能順利地運(yùn)行下去。顯然這樣的方法很麻煩，每個(gè)程序都要寫overlay manager也不太優(yōu)雅。

1.4 分頁內(nèi)存管理

于是第三代內(nèi)存管理方式，虛擬內(nèi)存管理(分頁內(nèi)存管理)誕生了。虛擬內(nèi)存管理也是需要硬件的支持和軟件的配合。在虛擬內(nèi)存中，CPU訪問任何內(nèi)存都是通過虛擬內(nèi)存地址來訪問的，但是實(shí)際上最終訪問內(nèi)存還是得用物理內(nèi)存地址。所以在CPU中存在一個(gè)MMU，負(fù)責(zé)把虛擬地址轉(zhuǎn)化為物理地址，然后再去訪問內(nèi)存。而MMU把虛擬地址轉(zhuǎn)化為物理的過程需要頁表的支持，頁表是由內(nèi)核負(fù)責(zé)創(chuàng)建和維護(hù)的。一套頁表可以用來表達(dá)一個(gè)虛擬內(nèi)存空間，不同的進(jìn)程可以用不同的頁表集，頁表集是可以不停地切換的，哪個(gè)進(jìn)程正在運(yùn)行就切換到哪個(gè)進(jìn)程的頁表集。于是一個(gè)進(jìn)程就只能訪問自己的虛擬內(nèi)存空間，而訪問不了別人的虛擬內(nèi)存空間，這樣就實(shí)現(xiàn)了進(jìn)程之間的隔離。一個(gè)虛擬內(nèi)存空間又分為兩部分，內(nèi)核空間和用戶空間，內(nèi)核空間只有一個(gè)，用戶空間有N個(gè)，所有的虛擬內(nèi)存空間都共享同一個(gè)內(nèi)核空間。內(nèi)核運(yùn)行在內(nèi)核空間，進(jìn)程運(yùn)行在用戶空間，內(nèi)核空間有特權(quán)，用戶空間無特權(quán)，用戶空間不能隨意訪問內(nèi)核空間。這樣進(jìn)程和內(nèi)核之間的隔離就形成了。內(nèi)核空間的代碼運(yùn)行的時(shí)候，CPU會(huì)把自己設(shè)置為特權(quán)模式，可以執(zhí)行所有的指令。用戶空間運(yùn)行的時(shí)候，CPU會(huì)把自己設(shè)置為用戶模式，只能執(zhí)行普通指令，不能執(zhí)行敏感指令。

至此，分段內(nèi)存實(shí)現(xiàn)的功能，虛擬內(nèi)存都做到了，下面就是虛擬內(nèi)存如何解決物理內(nèi)存不足的問題了。系統(tǒng)剛啟動(dòng)的時(shí)候還是運(yùn)行在物理內(nèi)存上的，內(nèi)核也被全部加載到了物理內(nèi)存。然后內(nèi)核建立頁表體系并開啟分頁機(jī)制，內(nèi)核的物理內(nèi)存和虛擬內(nèi)存就建立映射了，整個(gè)系統(tǒng)就運(yùn)行在虛擬內(nèi)存上了。后面運(yùn)行進(jìn)程的時(shí)候就不是這樣了，內(nèi)核會(huì)記錄進(jìn)程的虛擬內(nèi)存分配情況，但是并不會(huì)馬上分配物理內(nèi)存建立頁表映射，而是讓進(jìn)程先運(yùn)行著。進(jìn)程運(yùn)行的時(shí)候，CPU都是通過MMU訪問虛擬內(nèi)存地址的，MMU會(huì)用頁表去解析虛擬內(nèi)存，如果找到了其對(duì)應(yīng)的物理地址就直接訪問，如果頁表項(xiàng)是空的，就會(huì)觸發(fā)缺頁異常，在缺頁異常中會(huì)去分配物理內(nèi)存并建立頁表映射。然后再重新執(zhí)行剛才的那條指令，然后CPU還是通過MMU訪問內(nèi)存，由于頁表建立好了，這下就可以訪問到物理內(nèi)存了。當(dāng)物理內(nèi)存不足的時(shí)候，內(nèi)核還會(huì)把一部分物理內(nèi)存解除映射，把其內(nèi)容存放到外存中，等其再次需要的時(shí)候再加載回來。這樣，一個(gè)進(jìn)程運(yùn)行的時(shí)候并不需要立馬加載其全部?jī)?nèi)容到物理內(nèi)存，進(jìn)程只需要少量的物理內(nèi)存就能順利地運(yùn)行，于是系統(tǒng)運(yùn)行進(jìn)程的吞吐量就大大提高了。

分頁內(nèi)存管理不僅實(shí)現(xiàn)了分段內(nèi)存管理的功能，還有額外的優(yōu)點(diǎn)，于是分段內(nèi)存管理就沒有存在的意義了。但是這里面還有一個(gè)歷史包袱問題。對(duì)于那些比較新的CPU，比如ARM、RISC-V，它們沒有歷史包袱，直接實(shí)現(xiàn)的就是分頁內(nèi)存管理，根本不存在分段機(jī)制。但是對(duì)于x86就不一樣了，x86是從直接物理內(nèi)存、分段內(nèi)存、分頁內(nèi)存一步一步走過來的，有著沉重的歷史包袱。在x86 32上，分段機(jī)制和分頁機(jī)制是并存的，系統(tǒng)可以選擇只使用分段機(jī)制或者兩種機(jī)制都使用。Linux的選擇是使用分頁機(jī)制，并在邏輯上屏蔽分段機(jī)制，因?yàn)榉侄螜C(jī)制是不能禁用的。邏輯上屏蔽分段機(jī)制的方法是，所有段的段基址都是0，段限長都是最大值，這樣就相當(dāng)于是不分段了。分段機(jī)制無法禁用的原因是因?yàn)镃PU特權(quán)級(jí)是在分段機(jī)制中實(shí)現(xiàn)的，分頁機(jī)制沒有單獨(dú)的CPU特權(quán)級(jí)機(jī)制。所以Linux創(chuàng)建了4個(gè)段，__KERNEL_CS、__KERNEL_DS用于內(nèi)核空間，__USER_CS、__USER_DS用于用戶空間，它們?cè)跁?huì)空間切換時(shí)自動(dòng)切換，這樣CPU特權(quán)級(jí)就跟著切換了。對(duì)于x86 64，從硬件上基本屏蔽了分段，因?yàn)橛布?guī)定CS、DS、ES、SS這些段的段基址必須是0，段限長必須是最大值，軟件設(shè)置其它值也沒用。

因此我們?cè)谶@里要強(qiáng)調(diào)一句，分段機(jī)制早就是歷史了，x86 64已經(jīng)從硬件上屏蔽了分段機(jī)制，Linux早就從軟件上屏蔽了分段機(jī)制。X86 CPU的寄存器CS、DS、ES、FS和內(nèi)核的__KERNEL_CS、__KERNEL_DS、__USER_CS、__USER_DS，已經(jīng)不具有分段的意義了，它們的作用是為了實(shí)現(xiàn)CPU特權(quán)級(jí)的切換。

1.5 內(nèi)存管理的目標(biāo)

內(nèi)存管理的目標(biāo)除了前面所說的進(jìn)程之間的隔離、進(jìn)程與內(nèi)核之間的隔離、減少物理內(nèi)存并發(fā)使用的數(shù)量之外，還有以下幾個(gè)目標(biāo)。

1.減少內(nèi)存碎片，包括外部碎片和內(nèi)部碎片。外部碎片是指還在內(nèi)存分配器中的內(nèi)存，但是由于比較分散，無法滿足用戶大塊連續(xù)內(nèi)存分配的申請(qǐng)。內(nèi)部碎片是指你申請(qǐng)了5個(gè)字節(jié)的內(nèi)存，分配器給你分配了8個(gè)字節(jié)的內(nèi)存，其中3個(gè)字節(jié)的內(nèi)存是內(nèi)部碎片。內(nèi)存管理要盡量同時(shí)減少外部碎片和內(nèi)部碎片。

2.內(nèi)存分配接口要靈活多樣，同時(shí)滿足多種不同的內(nèi)存分配需求。既要滿足大塊連續(xù)內(nèi)存分配的需求，又能滿足小塊零碎內(nèi)存分配的需求。

3.內(nèi)存分配效率要高。內(nèi)存分配要盡量快地完成，比如說你設(shè)計(jì)了一種算法，能完全解決內(nèi)存碎片問題，但是內(nèi)存算法實(shí)現(xiàn)得特別復(fù)雜，每次分配都需要1毫秒的時(shí)間，這就不可取了。

4.提高物理內(nèi)存的利用率。比如及時(shí)回收物理內(nèi)存、對(duì)內(nèi)存進(jìn)行壓縮。

1.6 Linux內(nèi)存管理體系

Linux內(nèi)存管理的整體模式是虛擬內(nèi)存管理(分頁內(nèi)存管理)，并在此基礎(chǔ)上建立了一個(gè)龐大的內(nèi)存管理體系。我們先來看一下總體結(jié)構(gòu)圖。

整個(gè)體系分為3部分，左邊是物理內(nèi)存，右邊是虛擬內(nèi)存，中間是虛擬內(nèi)存映射(分頁機(jī)制)。我們先從物理內(nèi)存說起，內(nèi)存管理的基礎(chǔ)還是物理內(nèi)存的管理。

物理內(nèi)存那么大，應(yīng)該怎么管理呢？首先要對(duì)物理內(nèi)存進(jìn)行層級(jí)區(qū)劃，其原理可以類比于我國的行政區(qū)劃管理。我國幅員遼闊，國家直接管理個(gè)人肯定是不行的，我國采取的是省縣鄉(xiāng)三級(jí)管理體系。把整個(gè)國家按照一定的規(guī)則和歷史原因分成若干個(gè)省，每個(gè)省由省長管理。每個(gè)省再分成若干個(gè)縣，每個(gè)縣由縣長管理。每個(gè)縣再分成若干個(gè)鄉(xiāng)，每個(gè)鄉(xiāng)由鄉(xiāng)長管理，鄉(xiāng)長直接管理個(gè)人。(注意，類比是理解工具，不是論證工具)。對(duì)應(yīng)的，物理內(nèi)存也是采用類似的三級(jí)區(qū)域劃分的方式來管理的，三個(gè)層級(jí)分別叫做節(jié)點(diǎn)(node)、區(qū)域(zone)、頁面(page)，對(duì)應(yīng)到省、縣、鄉(xiāng)。系統(tǒng)首先把整個(gè)物理內(nèi)存劃分為N個(gè)節(jié)點(diǎn)，內(nèi)存節(jié)點(diǎn)只是叫節(jié)點(diǎn)，大家不能把它看成一個(gè)點(diǎn)，要把它看成是相當(dāng)于一個(gè)省的大區(qū)域。每個(gè)節(jié)點(diǎn)都有一個(gè)節(jié)點(diǎn)描述符，相當(dāng)于是省長。節(jié)點(diǎn)下面再劃分區(qū)域，每個(gè)區(qū)域都有區(qū)域描述符，相當(dāng)于是縣長。區(qū)域下面再劃分頁面，每個(gè)頁面都有頁面描述符，相當(dāng)于是鄉(xiāng)長。頁面再下面就是字節(jié)了，相當(dāng)于是個(gè)人。

對(duì)物理內(nèi)存建立三級(jí)區(qū)域劃分之后，就可以在其基礎(chǔ)之上建立分配體系了。物理內(nèi)存的分配體系可以類比于一個(gè)公司的銷售體系，有工廠直接進(jìn)行大額銷售，有批發(fā)公司進(jìn)行大量批發(fā)，有小賣部進(jìn)行日常零售。物理內(nèi)存的三級(jí)分配體系分別是buddy system、slab allocator和kmalloc。buddy system相當(dāng)于是工廠銷售，slab allocator相當(dāng)于是批發(fā)公司，kmalloc相當(dāng)于是小賣部，分別滿足人們不同規(guī)模的需求。

物理內(nèi)存有分配也有釋放，但是當(dāng)分配速度大于釋放速度的時(shí)候，物理內(nèi)存就會(huì)逐漸變得不夠用了。此時(shí)我們就要進(jìn)行內(nèi)存回收了。內(nèi)存回收首先考慮的是內(nèi)存規(guī)整，也就是內(nèi)存碎片整理，因?yàn)橛锌赡芪覀儾皇强捎脙?nèi)存不足了，而是內(nèi)存太分散了，沒法分配連續(xù)的內(nèi)存。內(nèi)存規(guī)整之后如果還是分配不到內(nèi)存的話，就會(huì)進(jìn)行頁幀回收。內(nèi)核的物理內(nèi)存是不換頁的，所以內(nèi)核只會(huì)進(jìn)行緩存回收。用戶空間的物理內(nèi)存是可以換頁的，所以會(huì)對(duì)用戶空間的物理內(nèi)存進(jìn)行換頁以便回收其物理內(nèi)存。用戶空間的物理內(nèi)存分為文件頁和匿名頁。對(duì)于文件頁，如果其是clean的，可以直接丟棄內(nèi)容，回收其物理內(nèi)存，如果其是dirty的，則會(huì)先把其內(nèi)容寫回到文件，然后再回收內(nèi)存。對(duì)于匿名頁，如果系統(tǒng)配置的有swap區(qū)的話，則會(huì)把其內(nèi)容先寫入swap區(qū)，然后再回收，如果系統(tǒng)沒有swap區(qū)的話則不會(huì)進(jìn)行回收。把進(jìn)程占用的但是當(dāng)前并不在使用的物理內(nèi)存進(jìn)行回收，并分配給新的進(jìn)程來使用的過程就叫做換頁。進(jìn)程被換頁的物理內(nèi)存后面如果再被使用到的話，還會(huì)通過缺頁異常再換入內(nèi)存。如果頁幀回收之后還沒有得到足夠的物理內(nèi)存，內(nèi)核將會(huì)使用最后一招，OOM Killer。OOM Killer會(huì)按照一定的規(guī)則選擇一個(gè)進(jìn)程將其殺死，然后其物理內(nèi)存就被釋放了。

內(nèi)核還有三個(gè)內(nèi)存壓縮技術(shù)zram、zswap、zcache，圖里并沒有畫出來。它們產(chǎn)生的原因并不相同，zram和zswap產(chǎn)生的原因是因?yàn)榘涯涿搶懭雜wap區(qū)是IO操作，是非常耗時(shí)的，使用zram和zswap可以達(dá)到用空間換時(shí)間的效果。zcache產(chǎn)生的原因是因?yàn)閮?nèi)核一般都有大量的pagecache，pagecache是對(duì)文件的緩存，有些文件緩存暫時(shí)用不到，可以對(duì)它們進(jìn)行壓縮，以節(jié)省內(nèi)存空間，到用的時(shí)候再解壓縮，以達(dá)到用時(shí)間換空間的效果。

物理內(nèi)存的這些操作都是在內(nèi)核里進(jìn)行的，但是CPU訪問內(nèi)存用的并不是物理內(nèi)存地址，而是虛擬內(nèi)存地址。內(nèi)核需要建立頁表把虛擬內(nèi)存映射到物理內(nèi)存上，然后CPU就可以通過MMU用虛擬地址來訪問物理內(nèi)存了。虛擬內(nèi)存地址空間分為兩部分，內(nèi)核空間和用戶空間。內(nèi)核空間只有一個(gè)，其頁表映射是在內(nèi)核啟動(dòng)的早期就建立的。用戶空間有N個(gè)，用戶空間是隨著進(jìn)程的創(chuàng)建而建立的，但是其頁表映射并不是馬上建立，而是在程序的運(yùn)行過程中通過缺頁異常逐步建立的。內(nèi)核頁表建立好了之后就不會(huì)再取消了，所以內(nèi)核是不換頁的，用戶頁表建立之后可能會(huì)因?yàn)閮?nèi)存回收而取消，所以用戶空間是換頁的。內(nèi)核頁表是在內(nèi)核啟動(dòng)時(shí)建立的，所以內(nèi)核空間的映射是線性映射，用戶空間的頁表是在運(yùn)行時(shí)動(dòng)態(tài)創(chuàng)建的，不可能做到線性映射，所以是隨機(jī)映射。

有些書上會(huì)說用戶空間是分頁的，內(nèi)核是不分頁的，這是對(duì)英語paging的錯(cuò)誤翻譯，paging在這里不是分頁的意思，而是換頁的意思。分頁是指整個(gè)分頁機(jī)制，換頁是內(nèi)存回收中的操作，兩者的含義是完全不同的。

現(xiàn)在我們對(duì)Linux內(nèi)存管理體系已經(jīng)有了宏觀上的了解，下面我們就來對(duì)每個(gè)模塊進(jìn)行具體地分析。

二、物理內(nèi)存區(qū)劃

內(nèi)核對(duì)物理內(nèi)存進(jìn)行了三級(jí)區(qū)劃。為什么要進(jìn)行三級(jí)區(qū)劃，具體怎么劃分的呢？這個(gè)不是軟件隨意決定的，而是和硬件因素有關(guān)。下面我們來看一下每一層級(jí)劃分的原因，以及軟件上是如果描述的。

2.1 物理內(nèi)存節(jié)點(diǎn)

我國的省為什么要按照現(xiàn)在的這個(gè)形狀來劃分呢，主要是依據(jù)山川地形還有民俗風(fēng)情等歷史原因。那么物理內(nèi)存劃分為節(jié)點(diǎn)的原因是什么呢？這就要從UMA、NUMA說起了。我們用三個(gè)圖來看一下。

圖中的CPU都是物理CPU。當(dāng)一個(gè)系統(tǒng)中的CPU越來越多、內(nèi)存越來越多的時(shí)候，內(nèi)存總線就會(huì)成為一個(gè)系統(tǒng)的瓶頸。如果大家都還擠在同一個(gè)總線上，速度必然很慢。于是我們可以采取一種方法，把一部分CPU和一部分內(nèi)存直連在一起，構(gòu)成一個(gè)節(jié)點(diǎn)，不同節(jié)點(diǎn)之間CPU訪問內(nèi)存采用間接方式。節(jié)點(diǎn)內(nèi)的內(nèi)存訪問速度就會(huì)很快，節(jié)點(diǎn)之間的內(nèi)存訪問速度雖然很慢，但是我們可以盡量減少節(jié)點(diǎn)之間的內(nèi)存訪問，這樣系統(tǒng)總的內(nèi)存訪問速度就會(huì)很快。

Linux中的代碼對(duì)UMA和NUMA是統(tǒng)一處理的，因?yàn)閁MA可以看成是只有一個(gè)節(jié)點(diǎn)的NUMA。如果編譯內(nèi)核時(shí)配置了CONFIG_NUMA，內(nèi)核支持NUMA架構(gòu)的計(jì)算機(jī)，內(nèi)核中會(huì)定義節(jié)點(diǎn)指針數(shù)組來表示各個(gè)node。如果編譯內(nèi)核時(shí)沒有配置CONFIG_NUMA，則內(nèi)核只支持UMA架構(gòu)的計(jì)算機(jī)，內(nèi)核中會(huì)定義一個(gè)內(nèi)存節(jié)點(diǎn)。這樣所有其它的代碼都可以統(tǒng)一處理了。

下面我們先來看一下節(jié)點(diǎn)描述符的定義。linux-src/include/linux/mmzone.h

typedef?struct?pglist_data?{
?/*
??*?node_zones?contains?just?the?zones?for?THIS?node.?Not?all?of?the
??*?zones?may?be?populated,?but?it?is?the?full?list.?It?is?referenced?by
??*?this?node's?node_zonelists?as?well?as?other?node's?node_zonelists.
??*/
?struct?zone?node_zones[MAX_NR_ZONES];

?/*
??*?node_zonelists?contains?references?to?all?zones?in?all?nodes.
??*?Generally?the?first?zones?will?be?references?to?this?node's
??*?node_zones.
??*/
?struct?zonelist?node_zonelists[MAX_ZONELISTS];

?int?nr_zones;?/*?number?of?populated?zones?in?this?node?*/
#ifdef?CONFIG_FLATMEM?/*?means?!SPARSEMEM?*/
?struct?page?*node_mem_map;
#ifdef?CONFIG_PAGE_EXTENSION
?struct?page_ext?*node_page_ext;
#endif
#endif
#if?defined(CONFIG_MEMORY_HOTPLUG)?||?defined(CONFIG_DEFERRED_STRUCT_PAGE_INIT)
?/*
??*?Must?be?held?any?time?you?expect?node_start_pfn,
??*?node_present_pages,?node_spanned_pages?or?nr_zones?to?stay?constant.
??*?Also?synchronizes?pgdat->first_deferred_pfn?during?deferred?page
??*?init.
??*
??*?pgdat_resize_lock()?and?pgdat_resize_unlock()?are?provided?to
??*?manipulate?node_size_lock?without?checking?for?CONFIG_MEMORY_HOTPLUG
??*?or?CONFIG_DEFERRED_STRUCT_PAGE_INIT.
??*
??*?Nests?above?zone->lock?and?zone->span_seqlock
??*/
?spinlock_t?node_size_lock;
#endif
?unsigned?long?node_start_pfn;
?unsigned?long?node_present_pages;?/*?total?number?of?physical?pages?*/
?unsigned?long?node_spanned_pages;?/*?total?size?of?physical?page
??????????range,?including?holes?*/
?int?node_id;
?wait_queue_head_t?kswapd_wait;
?wait_queue_head_t?pfmemalloc_wait;
?struct?task_struct?*kswapd;?/*?Protected?by
????????mem_hotplug_begin/end()?*/
?int?kswapd_order;
?enum?zone_type?kswapd_highest_zoneidx;

?int?kswapd_failures;??/*?Number?of?'reclaimed?==?0'?runs?*/

#ifdef?CONFIG_COMPACTION
?int?kcompactd_max_order;
?enum?zone_type?kcompactd_highest_zoneidx;
?wait_queue_head_t?kcompactd_wait;
?struct?task_struct?*kcompactd;
?bool?proactive_compact_trigger;
#endif
?/*
??*?This?is?a?per-node?reserve?of?pages?that?are?not?available
??*?to?userspace?allocations.
??*/
?unsigned?long??totalreserve_pages;

#ifdef?CONFIG_NUMA
?/*
??*?node?reclaim?becomes?active?if?more?unmapped?pages?exist.
??*/
?unsigned?long??min_unmapped_pages;
?unsigned?long??min_slab_pages;
#endif?/*?CONFIG_NUMA?*/

?/*?Write-intensive?fields?used?by?page?reclaim?*/
?ZONE_PADDING(_pad1_)

#ifdef?CONFIG_DEFERRED_STRUCT_PAGE_INIT
?/*
??*?If?memory?initialisation?on?large?machines?is?deferred?then?this
??*?is?the?first?PFN?that?needs?to?be?initialised.
??*/
?unsigned?long?first_deferred_pfn;
#endif?/*?CONFIG_DEFERRED_STRUCT_PAGE_INIT?*/

#ifdef?CONFIG_TRANSPARENT_HUGEPAGE
?struct?deferred_split?deferred_split_queue;
#endif

?/*?Fields?commonly?accessed?by?the?page?reclaim?scanner?*/

?/*
??*?NOTE:?THIS?IS?UNUSED?IF?MEMCG?IS?ENABLED.
??*
??*?Use?mem_cgroup_lruvec()?to?look?up?lruvecs.
??*/
?struct?lruvec??__lruvec;

?unsigned?long??flags;

?ZONE_PADDING(_pad2_)

?/*?Per-node?vmstats?*/
?struct?per_cpu_nodestat?__percpu?*per_cpu_nodestats;
?atomic_long_t??vm_stat[NR_VM_NODE_STAT_ITEMS];
}?pg_data_t;

對(duì)于UMA，內(nèi)核會(huì)定義唯一的一個(gè)節(jié)點(diǎn)。linux-src/mm/memblock.c

#ifndef?CONFIG_NUMA
struct?pglist_data?__refdata?contig_page_data;
EXPORT_SYMBOL(contig_page_data);
#endif

查找內(nèi)存節(jié)點(diǎn)的代碼如下：linux-src/include/linux/mmzone.h

extern?struct?pglist_data?contig_page_data;
static?inline?struct?pglist_data?*NODE_DATA(int?nid)
{
?return?&contig_page_data;
}

對(duì)于NUMA，內(nèi)核會(huì)定義內(nèi)存節(jié)點(diǎn)指針數(shù)組，不同架構(gòu)定義的不一定相同，我們以x86為例。linux-src/arch/x86/mm/numa.c

struct?pglist_data?*node_data[MAX_NUMNODES]?__read_mostly;
EXPORT_SYMBOL(node_data);

查找內(nèi)存節(jié)點(diǎn)的代碼如下：linux-src/arch/x86/include/asm/mmzone_64.h

extern?struct?pglist_data?*node_data[];
#define?NODE_DATA(nid)??(node_data[nid])

可以看出對(duì)于UMA，Linux是統(tǒng)一定義一個(gè)內(nèi)存節(jié)點(diǎn)的，對(duì)于NUMA，Linux是在各架構(gòu)代碼下定義內(nèi)存節(jié)點(diǎn)的。由于我們常見的電腦手機(jī)都是UMA的，后面的我們都以UMA為例進(jìn)行講解。pglist_data各自字段的含義我們?cè)谟玫綍r(shí)再進(jìn)行分析。

2.2 物理內(nèi)存區(qū)域

內(nèi)存節(jié)點(diǎn)下面再劃分為不同的區(qū)域。劃分區(qū)域的原因是什么呢？主要是因?yàn)楦鞣N軟硬件的限制導(dǎo)致的。目前Linux中最多可以有6個(gè)區(qū)域，這些區(qū)域并不是每個(gè)都必然存在，有的是由config控制的。有些區(qū)域就算代碼中配置了，但是在系統(tǒng)運(yùn)行的時(shí)候也可能為空。下面我們依次介紹一下這6個(gè)區(qū)域。

ZONE_DMA：由配置項(xiàng)CONFIG_ZONE_DMA決定是否存在。在x86上DMA內(nèi)存區(qū)域是物理內(nèi)存的前16M，這是因?yàn)樵缙诘腎SA總線上的DMA控制器只有24根地址總線，只能訪問16M物理內(nèi)存。為了兼容這些老的設(shè)備，所以需要專門開辟前16M物理內(nèi)存作為一個(gè)區(qū)域供這些設(shè)備進(jìn)行DMA操作時(shí)去分配物理內(nèi)存。

ZONE_DMA32：由配置項(xiàng)CONFIG_ZONE_DMA32決定是否存在。后來的DMA控制器有32根地址總線，可以訪問4G物理內(nèi)存了。但是在32位的系統(tǒng)上最多只支持4G物理內(nèi)存，所以沒必要專門劃分一個(gè)區(qū)域。但是到了64位系統(tǒng)時(shí)候，很多CPU能支持48位到52位的物理內(nèi)存，于是此時(shí)就有必要專門開個(gè)區(qū)域給32位的DMA控制器使用了。

ZONE_NORMAL：常規(guī)內(nèi)存，無配置項(xiàng)控制，必然存在，除了其它幾個(gè)內(nèi)存區(qū)域之外的內(nèi)存都是常規(guī)內(nèi)存ZONE_NORMAL。

ZONE_HIGHMEM：高端內(nèi)存，由配置項(xiàng)CONFIG_HIGHMEM決定是否存在。只在32位系統(tǒng)上有，這是因?yàn)?2位系統(tǒng)的內(nèi)核空間只有1G，這1G虛擬空間中還有128M用于其它用途，所以只有896M虛擬內(nèi)存空間用于直接映射物理內(nèi)存，而32位系統(tǒng)支持的物理內(nèi)存有4G，大于896M的物理內(nèi)存是無法直接映射到內(nèi)核空間的，所以把它們劃為高端內(nèi)存進(jìn)行特殊處理。對(duì)于64位系統(tǒng)，從理論上來說，內(nèi)核空間最大263-1，物理內(nèi)存最大264，好像內(nèi)核空間還是不夠用。但是從現(xiàn)實(shí)來說，內(nèi)核空間的一般配置為247，高達(dá)128T，物理內(nèi)存暫時(shí)還遠(yuǎn)遠(yuǎn)沒有這么多。所以從現(xiàn)實(shí)的角度來說，64位系統(tǒng)是不需要高端內(nèi)存區(qū)域的。

ZONE_MOVABLE：可移動(dòng)內(nèi)存，無配置項(xiàng)控制，必然存在，用于可熱插拔的內(nèi)存。內(nèi)核啟動(dòng)參數(shù)movablecore用于指定此區(qū)域的大小。內(nèi)核參數(shù)kernelcore也可用于指定非可移動(dòng)內(nèi)存的大小，剩余的內(nèi)存都是可移動(dòng)內(nèi)存。如果兩者同時(shí)指定的話，則會(huì)優(yōu)先保證非可移動(dòng)內(nèi)存的大小至少有kernelcore這么大。如果兩者都沒指定，則可移動(dòng)內(nèi)存大小為0。

ZONE_DEVICE：設(shè)備內(nèi)存，由配置項(xiàng)CONFIG_ZONE_DEVICE決定是否存在，用于放置持久內(nèi)存(也就是掉電后內(nèi)容不會(huì)消失的內(nèi)存)。一般的計(jì)算機(jī)中沒有這種內(nèi)存，默認(rèn)的內(nèi)存分配也不會(huì)從這里分配內(nèi)存。持久內(nèi)存可用于內(nèi)核崩潰時(shí)保存相關(guān)的調(diào)試信息。

下面我們先來看一下這幾個(gè)內(nèi)存區(qū)域的類型定義。linux-src/include/linux/mmzone.h

enum?zone_type?{
#ifdef?CONFIG_ZONE_DMA
?ZONE_DMA,
#endif
#ifdef?CONFIG_ZONE_DMA32
?ZONE_DMA32,
#endif
?ZONE_NORMAL,
#ifdef?CONFIG_HIGHMEM
?ZONE_HIGHMEM,
#endif
?ZONE_MOVABLE,
#ifdef?CONFIG_ZONE_DEVICE
?ZONE_DEVICE,
#endif
?__MAX_NR_ZONES
};

我們?cè)賮砜匆幌聟^(qū)域描述符的定義。linux-src/include/linux/mmzone.h

struct?zone?{
?/*?Read-mostly?fields?*/

?/*?zone?watermarks,?access?with?*_wmark_pages(zone)?macros?*/
?unsigned?long?_watermark[NR_WMARK];
?unsigned?long?watermark_boost;

?unsigned?long?nr_reserved_highatomic;

?/*
??*?We?don't?know?if?the?memory?that?we're?going?to?allocate?will?be
??*?freeable?or/and?it?will?be?released?eventually,?so?to?avoid?totally
??*?wasting?several?GB?of?ram?we?must?reserve?some?of?the?lower?zone
??*?memory?(otherwise?we?risk?to?run?OOM?on?the?lower?zones?despite
??*?there?being?tons?of?freeable?ram?on?the?higher?zones).??This?array?is
??*?recalculated?at?runtime?if?the?sysctl_lowmem_reserve_ratio?sysctl
??*?changes.
??*/
?long?lowmem_reserve[MAX_NR_ZONES];

#ifdef?CONFIG_NUMA
?int?node;
#endif
?struct?pglist_data?*zone_pgdat;
?struct?per_cpu_pages?__percpu?*per_cpu_pageset;
?struct?per_cpu_zonestat?__percpu?*per_cpu_zonestats;
?/*
??*?the?high?and?batch?values?are?copied?to?individual?pagesets?for
??*?faster?access
??*/
?int?pageset_high;
?int?pageset_batch;

#ifndef?CONFIG_SPARSEMEM
?/*
??*?Flags?for?a?pageblock_nr_pages?block.?See?pageblock-flags.h.
??*?In?SPARSEMEM,?this?map?is?stored?in?struct?mem_section
??*/
?unsigned?long??*pageblock_flags;
#endif?/*?CONFIG_SPARSEMEM?*/

?/*?zone_start_pfn?==?zone_start_paddr?>>?PAGE_SHIFT?*/
?unsigned?long??zone_start_pfn;

?atomic_long_t??managed_pages;
?unsigned?long??spanned_pages;
?unsigned?long??present_pages;
#if?defined(CONFIG_MEMORY_HOTPLUG)
?unsigned?long??present_early_pages;
#endif
#ifdef?CONFIG_CMA
?unsigned?long??cma_pages;
#endif

?const?char??*name;

#ifdef?CONFIG_MEMORY_ISOLATION
?/*
??*?Number?of?isolated?pageblock.?It?is?used?to?solve?incorrect
??*?freepage?counting?problem?due?to?racy?retrieving?migratetype
??*?of?pageblock.?Protected?by?zone->lock.
??*/
?unsigned?long??nr_isolate_pageblock;
#endif

#ifdef?CONFIG_MEMORY_HOTPLUG
?/*?see?spanned/present_pages?for?more?description?*/
?seqlock_t??span_seqlock;
#endif

?int?initialized;

?/*?Write-intensive?fields?used?from?the?page?allocator?*/
?ZONE_PADDING(_pad1_)

?/*?free?areas?of?different?sizes?*/
?struct?free_area?free_area[MAX_ORDER];

?/*?zone?flags,?see?below?*/
?unsigned?long??flags;

?/*?Primarily?protects?free_area?*/
?spinlock_t??lock;

?/*?Write-intensive?fields?used?by?compaction?and?vmstats.?*/
?ZONE_PADDING(_pad2_)

?/*
??*?When?free?pages?are?below?this?point,?additional?steps?are?taken
??*?when?reading?the?number?of?free?pages?to?avoid?per-cpu?counter
??*?drift?allowing?watermarks?to?be?breached
??*/
?unsigned?long?percpu_drift_mark;

#if?defined?CONFIG_COMPACTION?||?defined?CONFIG_CMA
?/*?pfn?where?compaction?free?scanner?should?start?*/
?unsigned?long??compact_cached_free_pfn;
?/*?pfn?where?compaction?migration?scanner?should?start?*/
?unsigned?long??compact_cached_migrate_pfn[ASYNC_AND_SYNC];
?unsigned?long??compact_init_migrate_pfn;
?unsigned?long??compact_init_free_pfn;
#endif

#ifdef?CONFIG_COMPACTION
?/*
??*?On?compaction?failure,?1<

	Zone結(jié)構(gòu)體中各個(gè)字段的含義我們?cè)谟玫降臅r(shí)候再進(jìn)行解釋。

	2.3 物理內(nèi)存頁面

	每個(gè)內(nèi)存區(qū)域下面再劃分為若干個(gè)面積比較小但是又不太小的頁面。頁面的大小一般都是4K，這是由硬件規(guī)定的。內(nèi)存節(jié)點(diǎn)和內(nèi)存區(qū)域從邏輯上來說并不是非得有，只不過是由于各種硬件限制或者特殊需求才有的。內(nèi)存頁面倒不是因?yàn)橛布拗撇庞械模饕浅鲇谶壿嬙虿庞械?。頁面是分頁?nèi)存機(jī)制和底層內(nèi)存分配的最小單元。如果沒有頁面的話，直接以字節(jié)為單位進(jìn)行管理顯然太麻煩了，所以需要有一個(gè)較小的基本單位，這個(gè)單位就叫做頁面。頁面的大小選多少合適呢？太大了不好，太小了也不好，這個(gè)數(shù)值還得是2的整數(shù)次冪，所以4K就非常合適。為啥是2的整數(shù)次冪呢？因?yàn)橛?jì)算機(jī)是用二進(jìn)制實(shí)現(xiàn)的，2的整數(shù)次冪做各種運(yùn)算和特殊處理比較方便，后面用到的時(shí)候就能體會(huì)到。為啥是4K呢？因?yàn)樽钤?a href="http://www.wenjunhu.com/tags/intel/" target="_blank">Intel選擇的就是4K，后面大部分CPU也都跟著選4K作為頁面的大小了。

	物理內(nèi)存頁面也叫做頁幀。物理內(nèi)存從開始起每4K、4K的，構(gòu)成一個(gè)個(gè)頁幀，這些頁幀的編號(hào)依次是0、1、2、3......。頁幀的編號(hào)也叫做pfn(page frame number)。很顯然，一個(gè)頁幀的物理地址和它的pfn有一個(gè)簡(jiǎn)單的數(shù)學(xué)關(guān)系，那就是其物理地址除以4K就是其pfn，其pfn乘以4K就是其物理地址。由于4K是2的整數(shù)次冪，所以這個(gè)乘除運(yùn)算可以轉(zhuǎn)化為移位運(yùn)算。下面我們看一下相關(guān)的宏操作。

	linux-src/include/linux/pfn.h
#define?PFN_ALIGN(x)?(((unsigned?long)(x)?+?(PAGE_SIZE?-?1))?&?PAGE_MASK)
#define?PFN_UP(x)?(((x)?+?PAGE_SIZE-1)?>>?PAGE_SHIFT)
#define?PFN_DOWN(x)?((x)?>>?PAGE_SHIFT)
#define?PFN_PHYS(x)?((phys_addr_t)(x)?<>?PAGE_SHIFT))

	PAGE_SHIFT的值在大部分平臺(tái)上都是等于12，2的12次方冪正好就是4K。

	下面我們來看一下頁面描述符的定義。linux-src/include/linux/mm_types.h
struct?page?{
?unsigned?long?flags;??/*?Atomic?flags,?some?possibly
??????*?updated?asynchronously?*/
?/*
??*?Five?words?(20/40?bytes)?are?available?in?this?union.
??*?WARNING:?bit?0?of?the?first?word?is?used?for?PageTail().?That
??*?means?the?other?users?of?this?union?MUST?NOT?use?the?bit?to
??*?avoid?collision?and?false-positive?PageTail().
??*/
?union?{
??struct?{?/*?Page?cache?and?anonymous?pages?*/
???/**
????*?@lru:?Pageout?list,?eg.?active_list?protected?by
????*?lruvec->lru_lock.??Sometimes?used?as?a?generic?list
????*?by?the?page?owner.
????*/
???struct?list_head?lru;
???/*?See?page-flags.h?for?PAGE_MAPPING_FLAGS?*/
???struct?address_space?*mapping;
???pgoff_t?index;??/*?Our?offset?within?mapping.?*/
???/**
????*?@private:?Mapping-private?opaque?data.
????*?Usually?used?for?buffer_heads?if?PagePrivate.
????*?Used?for?swp_entry_t?if?PageSwapCache.
????*?Indicates?order?in?the?buddy?system?if?PageBuddy.
????*/
???unsigned?long?private;
??};
??struct?{?/*?page_pool?used?by?netstack?*/
???/**
????*?@pp_magic:?magic?value?to?avoid?recycling?non
????*?page_pool?allocated?pages.
????*/
???unsigned?long?pp_magic;
???struct?page_pool?*pp;
???unsigned?long?_pp_mapping_pad;
???unsigned?long?dma_addr;
???union?{
????/**
?????*?dma_addr_upper:?might?require?a?64-bit
?????*?value?on?32-bit?architectures.
?????*/
????unsigned?long?dma_addr_upper;
????/**
?????*?For?frag?page?support,?not?supported?in
?????*?32-bit?architectures?with?64-bit?DMA.
?????*/
????atomic_long_t?pp_frag_count;
???};
??};
??struct?{?/*?slab,?slob?and?slub?*/
???union?{
????struct?list_head?slab_list;
????struct?{?/*?Partial?pages?*/
?????struct?page?*next;
#ifdef?CONFIG_64BIT
?????int?pages;?/*?Nr?of?pages?left?*/
?????int?pobjects;?/*?Approximate?count?*/
#else
?????short?int?pages;
?????short?int?pobjects;
#endif
????};
???};
???struct?kmem_cache?*slab_cache;?/*?not?slob?*/
???/*?Double-word?boundary?*/
???void?*freelist;??/*?first?free?object?*/
???union?{
????void?*s_mem;?/*?slab:?first?object?*/
????unsigned?long?counters;??/*?SLUB?*/
????struct?{???/*?SLUB?*/
?????unsigned?inuse:16;
?????unsigned?objects:15;
?????unsigned?frozen:1;
????};
???};
??};
??struct?{?/*?Tail?pages?of?compound?page?*/
???unsigned?long?compound_head;?/*?Bit?zero?is?set?*/

???/*?First?tail?page?only?*/
???unsigned?char?compound_dtor;
???unsigned?char?compound_order;
???atomic_t?compound_mapcount;
???unsigned?int?compound_nr;?/*?1?<ptl?*/
???unsigned?long?_pt_pad_2;?/*?mapping?*/
???union?{
????struct?mm_struct?*pt_mm;?/*?x86?pgds?only?*/
????atomic_t?pt_frag_refcount;?/*?powerpc?*/
???};
#if?ALLOC_SPLIT_PTLOCKS
???spinlock_t?*ptl;
#else
???spinlock_t?ptl;
#endif
??};
??struct?{?/*?ZONE_DEVICE?pages?*/
???/**?@pgmap:?Points?to?the?hosting?device?page?map.?*/
???struct?dev_pagemap?*pgmap;
???void?*zone_device_data;
???/*
????*?ZONE_DEVICE?private?pages?are?counted?as?being
????*?mapped?so?the?next?3?words?hold?the?mapping,?index,
????*?and?private?fields?from?the?source?anonymous?or
????*?page?cache?page?while?the?page?is?migrated?to?device
????*?private?memory.
????*?ZONE_DEVICE?MEMORY_DEVICE_FS_DAX?pages?also
????*?use?the?mapping,?index,?and?private?fields?when
????*?pmem?backed?DAX?files?are?mapped.
????*/
??};

??/**?@rcu_head:?You?can?use?this?to?free?a?page?by?RCU.?*/
??struct?rcu_head?rcu_head;
?};

?union?{??/*?This?union?is?4?bytes?in?size.?*/
??/*
???*?If?the?page?can?be?mapped?to?userspace,?encodes?the?number
???*?of?times?this?page?is?referenced?by?a?page?table.
???*/
??atomic_t?_mapcount;

??/*
???*?If?the?page?is?neither?PageSlab?nor?mappable?to?userspace,
???*?the?value?stored?here?may?help?determine?what?this?page
???*?is?used?for.??See?page-flags.h?for?a?list?of?page?types
???*?which?are?currently?stored?here.
???*/
??unsigned?int?page_type;

??unsigned?int?active;??/*?SLAB?*/
??int?units;???/*?SLOB?*/
?};

?/*?Usage?count.?*DO?NOT?USE?DIRECTLY*.?See?page_ref.h?*/
?atomic_t?_refcount;

#ifdef?CONFIG_MEMCG
?unsigned?long?memcg_data;
#endif

?/*
??*?On?machines?where?all?RAM?is?mapped?into?kernel?address?space,
??*?we?can?simply?calculate?the?virtual?address.?On?machines?with
??*?highmem?some?memory?is?mapped?into?kernel?virtual?memory
??*?dynamically,?so?we?need?a?place?to?store?that?address.
??*?Note?that?this?field?could?be?16?bits?on?x86?...?;)
??*
??*?Architectures?with?slow?multiplication?can?define
??*?WANT_PAGE_VIRTUAL?in?asm/page.h
??*/
#if?defined(WANT_PAGE_VIRTUAL)
?void?*virtual;???/*?Kernel?virtual?address?(NULL?if
????????not?kmapped,?ie.?highmem)?*/
#endif?/*?WANT_PAGE_VIRTUAL?*/

#ifdef?LAST_CPUPID_NOT_IN_PAGE_FLAGS
?int?_last_cpupid;
#endif
}?_struct_page_alignment;

	可以看到頁面描述符的定義非常復(fù)雜，各種共用體套共用體。為什么這么復(fù)雜呢？這是因?yàn)槲锢韮?nèi)存的每個(gè)頁幀都需要有一個(gè)頁面描述符。對(duì)于4G的物理內(nèi)存來說，需要有4G/4K=1M也就是100多萬個(gè)頁面描述符。所以竭盡全力地減少頁面描述符的大小是非常必要的。又由于頁面描述符記錄的很多數(shù)據(jù)不都是同時(shí)在使用的，所以可以使用共用體來減少頁面描述符的大小。頁面描述符中各個(gè)字段的含義，我們?cè)谟玫降臅r(shí)候再進(jìn)行解釋。

	2.4 物理內(nèi)存模型

	計(jì)算機(jī)中有很多名稱叫做內(nèi)存模型的概念，它們的含義并不相同，大家要注意區(qū)分。此處講的內(nèi)存模型是Linux對(duì)物理內(nèi)存地址空間連續(xù)性的抽象，用來表示物理內(nèi)存的地址空間是否有空洞以及該如何處理空洞，因此這個(gè)概念也被叫做內(nèi)存連續(xù)性模型。由于內(nèi)存熱插拔也會(huì)導(dǎo)致物理內(nèi)存地址空間產(chǎn)生空洞，因此Linux內(nèi)存模型也是內(nèi)存熱插拔的基礎(chǔ)。

	最開始的時(shí)候是沒有內(nèi)存模型的，后來有了其它的內(nèi)存模型，這個(gè)最開始的情況就被叫做平坦內(nèi)存模型(Flat Memory)。平坦內(nèi)存模型看到的物理內(nèi)存就是連續(xù)的沒有空洞的內(nèi)存。后來為了處理物理內(nèi)存有空洞的情況以及內(nèi)存熱插拔問題，又開發(fā)出了離散內(nèi)存模型(Discontiguous Memory)。但是離散內(nèi)存模型的實(shí)現(xiàn)復(fù)用了NUMA的代碼，導(dǎo)致NUMA和內(nèi)存模型的耦合，實(shí)際上二者在邏輯上是正交的。內(nèi)核后來又開發(fā)了稀疏內(nèi)存模型(Sparse Memory)，其實(shí)現(xiàn)和NUMA不再耦合在一起了，而且稀疏內(nèi)存模型能同時(shí)處理平坦內(nèi)存、稀疏內(nèi)存、極度稀疏內(nèi)存，還能很好地支持內(nèi)存熱插拔。于是離散內(nèi)存模型就先被棄用了，后又被移出了內(nèi)核?，F(xiàn)在內(nèi)核中就只有平坦內(nèi)存模型和稀疏內(nèi)存模型了。而且在很多架構(gòu)中，如x86、ARM64，稀疏內(nèi)存模型已經(jīng)變成了唯一的可選項(xiàng)了，也就是必選內(nèi)存模型。

	系統(tǒng)有一個(gè)頁面描述符的數(shù)組，用來描述系統(tǒng)中的所有頁幀。這個(gè)數(shù)組是在系統(tǒng)啟動(dòng)時(shí)創(chuàng)建的，然后有一個(gè)全局的指針變量會(huì)指向這個(gè)數(shù)組。這個(gè)變量的名字在平坦內(nèi)存中叫做mem_map，是全分配的，在稀疏內(nèi)存中叫做vmemmap，內(nèi)存空洞對(duì)應(yīng)的頁表描述符是不被映射的。學(xué)過C語言的人都知道指針與數(shù)組之間的關(guān)系，指針之間的減法以及指針與整數(shù)之間的加法與數(shù)組下標(biāo)的關(guān)系。因此我們可以把頁面描述符指針和頁幀號(hào)相互轉(zhuǎn)換。

	我們來看一下頁面描述符數(shù)組指針的定義和指針與頁幀號(hào)之間的轉(zhuǎn)換操作。linux-src/mm/memory.c
#ifndef?CONFIG_NUMA
struct?page?*mem_map;
EXPORT_SYMBOL(mem_map);
#endif

	linux-src/arch/x86/include/asm/pgtable_64.h
#define?vmemmap?((struct?page?*)VMEMMAP_START)

	linux-src/arch/x86/include/asm/pgtable_64_types.h
#ifdef?CONFIG_DYNAMIC_MEMORY_LAYOUT
#?define?VMEMMAP_START??vmemmap_base
#else
#?define?VMEMMAP_START??__VMEMMAP_BASE_L4
#endif?/*?CONFIG_DYNAMIC_MEMORY_LAYOUT?*/

	linux-src/include/asm-generic/memory_model.h
#if?defined(CONFIG_FLATMEM)

#ifndef?ARCH_PFN_OFFSET
#define?ARCH_PFN_OFFSET??(0UL)
#endif

#define?__pfn_to_page(pfn)?(mem_map?+?((pfn)?-?ARCH_PFN_OFFSET))
#define?__page_to_pfn(page)?((unsigned?long)((page)?-?mem_map)?+?
?????ARCH_PFN_OFFSET)

#elif?defined(CONFIG_SPARSEMEM_VMEMMAP)

/*?memmap?is?virtually?contiguous.??*/
#define?__pfn_to_page(pfn)?(vmemmap?+?(pfn))
#define?__page_to_pfn(page)?(unsigned?long)((page)?-?vmemmap)

#elif?defined(CONFIG_SPARSEMEM)
/*
?*?Note:?section's?mem_map?is?encoded?to?reflect?its?start_pfn.
?*?section[i].section_mem_map?==?mem_map's?address?-?start_pfn;
?*/
#define?__page_to_pfn(pg)?????
({?const?struct?page?*__pg?=?(pg);????
?int?__sec?=?page_to_section(__pg);???
?(unsigned?long)(__pg?-?__section_mem_map_addr(__nr_to_section(__sec)));?
})

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

/*
?*?Convert?a?physical?address?to?a?Page?Frame?Number?and?back
?*/
#define?__phys_to_pfn(paddr)?PHYS_PFN(paddr)
#define?__pfn_to_phys(pfn)?PFN_PHYS(pfn)

#define?page_to_pfn?__page_to_pfn
#define?pfn_to_page?__pfn_to_page

	2.5 三級(jí)區(qū)劃關(guān)系

	我們對(duì)物理內(nèi)存的三級(jí)區(qū)劃有了簡(jiǎn)單的了解，下面我們?cè)賹?duì)它們之間的關(guān)系進(jìn)行更進(jìn)一步地分析。雖然在節(jié)點(diǎn)描述符中包含了所有的區(qū)域類型，但是除了第一個(gè)節(jié)點(diǎn)能包含所有的區(qū)域類型之外，其它的節(jié)點(diǎn)并不能包含所有的區(qū)域類型，因?yàn)橛行﹨^(qū)域類型(DMA、DMA32)必須從物理內(nèi)存的起點(diǎn)開始。Normal、HighMem和Movable是可以出現(xiàn)在所有的節(jié)點(diǎn)上的。頁面編號(hào)(pfn)是從物理內(nèi)存的起點(diǎn)開始編號(hào)，不是每個(gè)節(jié)點(diǎn)或者區(qū)域重新編號(hào)的。所有區(qū)域的范圍都必須是整數(shù)倍個(gè)頁面，不能出現(xiàn)半個(gè)頁面。節(jié)點(diǎn)描述符不僅記錄自己所包含的區(qū)域，還會(huì)記錄自己的起始頁幀號(hào)和跨越頁幀數(shù)量，區(qū)域描述符也會(huì)記錄自己的起始頁幀號(hào)和跨越頁幀數(shù)量。

	下面我們來畫個(gè)圖看一下節(jié)點(diǎn)與頁面之間的關(guān)系以及x86上具體的區(qū)分劃分情況。

	

	三、物理內(nèi)存分配

	當(dāng)我們把物理內(nèi)存區(qū)劃弄明白之后，再來學(xué)習(xí)物理內(nèi)存分配就比較容易了。物理內(nèi)存分配最底層的是頁幀分配。頁幀分配的分配單元是區(qū)域，分配粒度是頁面。如何進(jìn)行頁幀分配呢？Linux采取的算法叫做伙伴系統(tǒng)(buddy system)。只有伙伴系統(tǒng)還不行，因?yàn)榛锇橄到y(tǒng)進(jìn)行的是大粒度的分配，我們還需要批發(fā)與零售，于是便有了slab allocator和kmalloc。這幾種內(nèi)存分配方法分配的都是線性映射的內(nèi)存，當(dāng)系統(tǒng)連續(xù)內(nèi)存不足的時(shí)候，Linux還提供了vmalloc用來分配非線性映射的內(nèi)存。下面我們畫圖來看一下它們之間的關(guān)系。

	

	Buddy System既是直接的內(nèi)存分配接口，也是所有其它內(nèi)存分配器的底層分配器。Slab建立在Buddy的基礎(chǔ)之上，Kmalloc又建立在Slab的基礎(chǔ)之上。Vmalloc和CMA也是建立在Buddy的基礎(chǔ)之上。Linux采取的這種內(nèi)存分配體系提供了豐富靈活的內(nèi)存接口，還能同時(shí)減少外部碎片和內(nèi)部碎片。

	3.1 Buddy System

	伙伴系統(tǒng)的基本管理單位是區(qū)域，最小分配粒度是頁面。因?yàn)榛锇橄到y(tǒng)是建立在物理內(nèi)存的三級(jí)區(qū)劃上的，所以最小分配粒度是頁面，不能比頁面再小了?；竟芾韱挝皇菂^(qū)域，是因?yàn)槊總€(gè)區(qū)域的內(nèi)存都有特殊的用途或者用法，不能隨便混用，所以不能用節(jié)點(diǎn)作為基本管理單位。伙伴系統(tǒng)并不是直接管理一個(gè)個(gè)頁幀的，而是把頁幀組成頁塊(pageblock)來管理，頁塊是由連續(xù)的2^n^個(gè)頁幀組成，n叫做這個(gè)頁塊的階，n的范圍是0到10。而且2^n^個(gè)頁幀還有對(duì)齊的要求，首頁幀的頁幀號(hào)(pfn)必須能除盡2^n^，比如3階頁塊的首頁幀(pfn)必須除以8(2^3^)能除盡，10階頁塊的首頁幀必須除以1024(2^10^)能除盡。0階頁塊只包含一個(gè)頁幀，任意一個(gè)頁幀都可以構(gòu)成一個(gè)0階頁塊，而且符合對(duì)齊要求，因?yàn)槿魏握麛?shù)除以1(2^0^)都能除盡。

	3.1.1 伙伴系統(tǒng)的內(nèi)存來源

	伙伴系統(tǒng)管理的內(nèi)存并不是全部的物理內(nèi)存，而是內(nèi)核在完成初步的初始化之后的未使用內(nèi)存。內(nèi)核在剛啟動(dòng)的時(shí)候有一個(gè)簡(jiǎn)單的早期內(nèi)存管理器，它會(huì)記錄系統(tǒng)的所有物理內(nèi)存以及在它之前就被占用的內(nèi)存，并為內(nèi)核提供早期的內(nèi)存分配服務(wù)。當(dāng)內(nèi)核的基礎(chǔ)初始化完成之后，它就會(huì)把所有剩余可用的物理內(nèi)存交給伙伴系統(tǒng)來管理，然后自己就退出歷史舞臺(tái)了。早期內(nèi)存管理器會(huì)首先嘗試把頁幀以10階頁塊的方式加入伙伴系統(tǒng)，不夠10階的以9階頁塊的方式加入伙伴系統(tǒng)，以此類推，直到以0階頁塊的方式把所有可用頁幀都加入到伙伴系統(tǒng)。顯而易見，內(nèi)核剛啟動(dòng)的時(shí)候高階頁塊比較多，低階頁塊比較少。早期內(nèi)存管理器以前是bootmem，后來是bootmem和memblock共存，可以通過config選擇使用哪一個(gè)，現(xiàn)在是只有memblock了，bootmem已經(jīng)被移出了內(nèi)核。

	3.1.2 伙伴系統(tǒng)的管理數(shù)據(jù)結(jié)構(gòu)

	伙伴系統(tǒng)的管理數(shù)據(jù)定義在區(qū)域描述符中，是結(jié)構(gòu)體free_area的數(shù)組，數(shù)組大小是11，因?yàn)閺?到10有11個(gè)數(shù)。free_area的定義如下所示：linux-src/include/linux/mmzone.h
struct?free_area?{
?struct?list_head?free_list[MIGRATE_TYPES];
?unsigned?long??nr_free;
};

enum?migratetype?{
?MIGRATE_UNMOVABLE,
?MIGRATE_MOVABLE,
?MIGRATE_RECLAIMABLE,
?MIGRATE_PCPTYPES,?/*?the?number?of?types?on?the?pcp?lists?*/
?MIGRATE_HIGHATOMIC?=?MIGRATE_PCPTYPES,
#ifdef?CONFIG_CMA
?/*
??*?MIGRATE_CMA?migration?type?is?designed?to?mimic?the?way
??*?ZONE_MOVABLE?works.??Only?movable?pages?can?be?allocated
??*?from?MIGRATE_CMA?pageblocks?and?page?allocator?never
??*?implicitly?change?migration?type?of?MIGRATE_CMA?pageblock.
??*
??*?The?way?to?use?it?is?to?change?migratetype?of?a?range?of
??*?pageblocks?to?MIGRATE_CMA?which?can?be?done?by
??*?__free_pageblock_cma()?function.??What?is?important?though
??*?is?that?a?range?of?pageblocks?must?be?aligned?to
??*?MAX_ORDER_NR_PAGES?should?biggest?page?be?bigger?than
??*?a?single?pageblock.
??*/
?MIGRATE_CMA,
#endif
#ifdef?CONFIG_MEMORY_ISOLATION
?MIGRATE_ISOLATE,?/*?can't?allocate?from?here?*/
#endif
?MIGRATE_TYPES
};

	可以看到free_area的定義非常簡(jiǎn)單，就是由MIGRATE_TYPES個(gè)鏈表組成，鏈表連接的是同一個(gè)階的遷移類型相同的頁幀。遷移類型是內(nèi)核為了減少內(nèi)存碎片而提出的技術(shù)，不同區(qū)域的頁塊有不同的默認(rèn)遷移類型，比如DMA、NORMAL默認(rèn)都是不可遷移(MIGRATE_UNMOVABLE)的頁塊,HIGHMEM、MOVABLE區(qū)域默認(rèn)都是可遷移(MIGRATE_UNMOVABLE)的頁塊。我們申請(qǐng)的內(nèi)存有時(shí)候是不可移動(dòng)的內(nèi)存，比如內(nèi)核線性映射的內(nèi)存，有時(shí)候是可以移動(dòng)的內(nèi)存，比如用戶空間缺頁異常分配的內(nèi)存。我們把不同遷移類型的內(nèi)存分開進(jìn)行分配，在進(jìn)行內(nèi)存碎片整理的時(shí)候就比較方便，不會(huì)出現(xiàn)一片可移動(dòng)內(nèi)存中夾著一個(gè)不可移動(dòng)的內(nèi)存(這種情況就很礙事)。如果要分配的遷移類型的內(nèi)存不足時(shí)就需要從其它的遷移類型中進(jìn)行盜頁了。內(nèi)核定義了每種遷移類型的后備類型，如下所示：linux-src/mm/page_alloc.c
/*
?*?This?array?describes?the?order?lists?are?fallen?back?to?when
?*?the?free?lists?for?the?desirable?migrate?type?are?depleted
?*/
static?int?fallbacks[MIGRATE_TYPES][3]?=?{
?[MIGRATE_UNMOVABLE]???=?{?MIGRATE_RECLAIMABLE,?MIGRATE_MOVABLE,???MIGRATE_TYPES?},
?[MIGRATE_MOVABLE]?????=?{?MIGRATE_RECLAIMABLE,?MIGRATE_UNMOVABLE,?MIGRATE_TYPES?},
?[MIGRATE_RECLAIMABLE]?=?{?MIGRATE_UNMOVABLE,???MIGRATE_MOVABLE,???MIGRATE_TYPES?},
#ifdef?CONFIG_CMA
?[MIGRATE_CMA]?????????=?{?MIGRATE_TYPES?},?/*?Never?used?*/
#endif
#ifdef?CONFIG_MEMORY_ISOLATION
?[MIGRATE_ISOLATE]?????=?{?MIGRATE_TYPES?},?/*?Never?used?*/
#endif
};

	一種遷移類型的頁塊被盜頁之后，它的遷移類型就改變了，所以一個(gè)頁塊的遷移類型是會(huì)改變的，有可能變來變?nèi)?。?dāng)物理內(nèi)存比較少時(shí)，這種變來變?nèi)ゾ蜁?huì)特別頻繁，這樣遷移類型帶來的好處就得不償失了。因此內(nèi)核定義了一個(gè)變量page_group_by_mobility_disabled，當(dāng)物理內(nèi)存比較少時(shí)就禁用遷移類型。

	伙伴系統(tǒng)管理頁塊的方式可以用下圖來表示：

	

	3.1.3 伙伴系統(tǒng)的算法邏輯

	伙伴系統(tǒng)對(duì)外提供的接口只能分配某一階的頁塊，并不能隨意分配若干個(gè)頁幀。當(dāng)分配n階頁塊時(shí)，伙伴系統(tǒng)會(huì)優(yōu)先查找n階頁塊的鏈表，如果不為空的話就拿出來一個(gè)分配。如果為空的就去找n+1階頁塊的鏈表，如果不為空的話，就拿出來一個(gè)，并分成兩個(gè)n階頁塊，其中一個(gè)加入n階頁塊的鏈表中，另一個(gè)分配出去。如果n+1階頁塊鏈表也是空的話，就去找n+2階頁塊的鏈表，如果不為空的話，就拿出來一個(gè)，然后分成兩個(gè)n+1階的頁塊，其中一個(gè)加入到n+1階的鏈表中去，剩下的一個(gè)再分成兩個(gè)n階頁塊，其中一個(gè)放入n階頁塊的鏈表中去，另一個(gè)分配出去。如果n+2階頁塊的鏈表也是空的，那就去找n+3階頁塊的鏈表，重復(fù)此邏輯，直到找到10階頁塊的鏈表。如果10階頁塊的鏈表也是空的話，那就去找后備遷移類型的頁塊去分配，此時(shí)從最高階的頁塊鏈表往低階頁塊的鏈表開始查找，直到查到為止。如果后備頁塊也分配不到內(nèi)存，那么就會(huì)進(jìn)行內(nèi)存回收，這是下一章的內(nèi)容。

	用戶用完內(nèi)存還給伙伴系統(tǒng)的時(shí)候，并不是直接還給其對(duì)應(yīng)的n階頁塊的鏈表就行了，而是會(huì)先進(jìn)行合并。比如你申請(qǐng)了一個(gè)0階頁塊，用完了之后要?dú)w還，我們假設(shè)其頁幀號(hào)是5，來推演一下其歸還過程。如果此時(shí)發(fā)現(xiàn)4號(hào)頁幀也是free的，則4和5會(huì)合并成一個(gè)1階頁塊，首頁幀號(hào)是4。如果4號(hào)頁幀不是free的，則5號(hào)頁幀直接還給0階頁塊鏈表中去。如果6號(hào)頁幀free呢，會(huì)不會(huì)和5號(hào)頁幀合并？不會(huì)，因?yàn)椴粷M足頁幀號(hào)對(duì)齊要求。如果5和6合并，將會(huì)成為一個(gè)1階頁塊，1階頁塊要求其首頁幀的頁號(hào)必須除以2(2^1^)能除盡，而5除以2除不盡，所以5和6不能合并。而4和5合并之后，4除以2(2^1^)是能除盡的。4和5合并成一個(gè)1階頁塊之后還要查看是否能繼續(xù)合并，如果此時(shí)有一個(gè)1階頁塊是free的，由6和7組成的，此時(shí)它們就會(huì)合并成一個(gè)2階頁塊，包含4、5、6、7共4個(gè)頁幀，而且符合對(duì)齊要求，4除以4(2^2^)是能除盡的。如果此時(shí)有一個(gè)1階頁塊是free的，由2和3組成的，那么就不能合并，因?yàn)楹喜⒑蟮氖醉搸?，2除以4(2^2^)是除不盡的。繼續(xù)此流程，如果合并后的n階頁塊的前面或者后面還有free的同階頁塊，而且也符合對(duì)齊要求，就會(huì)繼續(xù)合并，直到無法合并或者已經(jīng)到達(dá)了10階頁塊，才會(huì)停止合并，然后把其插入到對(duì)應(yīng)的頁塊鏈表中去。

	3.1.4 伙伴系統(tǒng)的接口

	下面我們來看一下伙伴系統(tǒng)的接口?；锇橄到y(tǒng)提供了兩類接口，一類是返回頁表描述符的，一類是返回虛擬內(nèi)存地址的。linux-src/include/linux/gfp.
struct?page?*alloc_pages(gfp_t?gfp,?unsigned?int?order);
#define?alloc_page(gfp_mask)?alloc_pages(gfp_mask,?0)
struct?page?*alloc_pages_node(int?nid,?gfp_t?gfp_mask,unsigned?int?order);
void?__free_pages(struct?page?*page,?unsigned?int?order);
#define?__free_page(page)?__free_pages((page),?0)

	釋放的接口很簡(jiǎn)單，只需要一個(gè)頁表描述符指針加一個(gè)階數(shù)。分配的接口中，有的會(huì)指定nodeid，就從那個(gè)節(jié)點(diǎn)中分配內(nèi)存。不指定nodeid的接口，如果是在UMA中，那就從唯一的節(jié)點(diǎn)中分配內(nèi)存，如果是NUMA，會(huì)按照一定的策略選擇在哪個(gè)節(jié)點(diǎn)中分配內(nèi)存。最復(fù)雜的參數(shù)是gfp，gfp是標(biāo)記參數(shù)，可以分為兩類標(biāo)記，一類是指定分配區(qū)域的，一類是指定分配行為的，下面我們來看一下。linux-src/include/linux/gfp.h
#define?___GFP_DMA??0x01u
#define?___GFP_HIGHMEM??0x02u
#define?___GFP_DMA32??0x04u
#define?___GFP_MOVABLE??0x08u
#define?___GFP_RECLAIMABLE?0x10u
#define?___GFP_HIGH??0x20u
#define?___GFP_IO??0x40u
#define?___GFP_FS??0x80u
#define?___GFP_ZERO??0x100u
#define?___GFP_ATOMIC??0x200u
#define?___GFP_DIRECT_RECLAIM?0x400u
#define?___GFP_KSWAPD_RECLAIM?0x800u
#define?___GFP_WRITE??0x1000u
#define?___GFP_NOWARN??0x2000u
#define?___GFP_RETRY_MAYFAIL?0x4000u
#define?___GFP_NOFAIL??0x8000u
#define?___GFP_NORETRY??0x10000u
#define?___GFP_MEMALLOC??0x20000u
#define?___GFP_COMP??0x40000u
#define?___GFP_NOMEMALLOC?0x80000u
#define?___GFP_HARDWALL??0x100000u
#define?___GFP_THISNODE??0x200000u
#define?___GFP_ACCOUNT??0x400000u
#define?___GFP_ZEROTAGS??0x800000u
#define?___GFP_SKIP_KASAN_POISON?0x1000000u
#ifdef?CONFIG_LOCKDEP
#define?___GFP_NOLOCKDEP?0x2000000u
#else
#define?___GFP_NOLOCKDEP?0
#endif

	其中前4個(gè)是指定分配區(qū)域的，內(nèi)核里一共定義了6類區(qū)域，為啥只有4個(gè)指示符呢？因?yàn)閆ONE_DEVICE有特殊用途，不在一般的內(nèi)存分配管理中，當(dāng)不指定區(qū)域類型時(shí)默認(rèn)就是ZONE_NORMAL，所以4個(gè)就夠了。是不是指定了哪個(gè)區(qū)域就只能在哪個(gè)區(qū)域分配內(nèi)存呢，不是的。每個(gè)區(qū)域都有后備區(qū)域，當(dāng)其內(nèi)存不足時(shí)，會(huì)從其后備區(qū)域中分配內(nèi)存。后備區(qū)域是在節(jié)點(diǎn)描述符中定義，我們來看一下：linux-src/include/linux/mmzone.h
typedef?struct?pglist_data?{
?struct?zonelist?node_zonelists[MAX_ZONELISTS];
}?pg_data_t;

enum?{
?ZONELIST_FALLBACK,?/*?zonelist?with?fallback?*/
#ifdef?CONFIG_NUMA
?/*
??*?The?NUMA?zonelists?are?doubled?because?we?need?zonelists?that
??*?restrict?the?allocations?to?a?single?node?for?__GFP_THISNODE.
??*/
?ZONELIST_NOFALLBACK,?/*?zonelist?without?fallback?(__GFP_THISNODE)?*/
#endif
?MAX_ZONELISTS
};

struct?zonelist?{
?struct?zoneref?_zonerefs[MAX_ZONES_PER_ZONELIST?+?1];
};

struct?zoneref?{
?struct?zone?*zone;?/*?Pointer?to?actual?zone?*/
?int?zone_idx;??/*?zone_idx(zoneref->zone)?*/
};

	在UMA上，后備區(qū)域只有一個(gè)鏈表，就是本節(jié)點(diǎn)內(nèi)的后備區(qū)域，在NUMA中后備區(qū)域有兩個(gè)鏈表，包括本節(jié)點(diǎn)內(nèi)的后備區(qū)域和其它節(jié)點(diǎn)的后備區(qū)域。這些后備區(qū)域是在內(nèi)核啟動(dòng)時(shí)初始化的。對(duì)于本節(jié)點(diǎn)的后備區(qū)域，是按照區(qū)域類型的id排列的，高id的排在前面，低id的排在后面，后面的是前面的后備，前面的區(qū)域內(nèi)存不足時(shí)可以從后面的區(qū)域里分配內(nèi)存，反過來則不行。比如MOVABLE區(qū)域的內(nèi)存不足時(shí)可以從NORMAL區(qū)域來分配，NORMAL區(qū)域的內(nèi)存不足時(shí)可以從DMA區(qū)域來分配，反過來則不行。對(duì)于其它節(jié)點(diǎn)的后備區(qū)域，除了會(huì)符合前面的規(guī)則之外，還會(huì)考慮后備區(qū)域是按照節(jié)點(diǎn)優(yōu)先的順序來排列還是按照區(qū)域類型優(yōu)先的順序來排列。

	下面我們?cè)賮砜匆幌路峙湫袨榈膄lag都是什么含義。

	__GFP_HIGH：調(diào)用者的優(yōu)先級(jí)很高，要盡量滿足分配請(qǐng)求。

	__GFP_ATOMIC：調(diào)用者處在原子場(chǎng)景中，分配過程不能回收頁或者睡眠，一般是中斷處理程序會(huì)用。

	__GFP_IO：可以進(jìn)行磁盤IO操作。

	__GFP_FS：可以進(jìn)行文件系統(tǒng)的操作。

	__GFP_KSWAPD_RECLAIM：當(dāng)內(nèi)存不足時(shí)允許異步回收。

	__GFP_RECLAIM：當(dāng)內(nèi)存不足時(shí)允許同步回收和異步回收。

	__GFP_REPEAT：允許重試，重試多次以后還是沒有內(nèi)存就返回失敗。

	__GFP_NOFAIL：不能失敗，必須無限次重試。

	__GFP_NORETRY：不要重試，當(dāng)直接回收和內(nèi)存規(guī)整之后還是分配不到內(nèi)存的話就返回失敗。

	__GFP_ZERO：把要分配的頁清零。

	還有一些其它的flag就不再一一進(jìn)行介紹了。

	如果我們每次分配內(nèi)存都把這些flag一一進(jìn)行組合，那就太麻煩了，所以系統(tǒng)為我們定義了一些常用的組合，如下所示：linux-src/include/linux/gfp.h
#define?GFP_ATOMIC?(__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
#define?GFP_KERNEL?(__GFP_RECLAIM?|?__GFP_IO?|?__GFP_FS)
#define?GFP_NOIO?(__GFP_RECLAIM)
#define?GFP_NOFS?(__GFP_RECLAIM?|?__GFP_IO)
#define?GFP_USER?(__GFP_RECLAIM?|?__GFP_IO?|?__GFP_FS?|?__GFP_HARDWALL)
#define?GFP_DMA??__GFP_DMA
#define?GFP_DMA32?__GFP_DMA32
#define?GFP_HIGHUSER?(GFP_USER?|?__GFP_HIGHMEM)
#define?GFP_HIGHUSER_MOVABLE?(GFP_HIGHUSER?|?__GFP_MOVABLE?|?__GFP_SKIP_KASAN_POISON)

	中斷中分配內(nèi)存一般用GFP_ATOMIC，內(nèi)核自己使用的內(nèi)存一般用GFP_KERNEL，為用戶空間分配內(nèi)存一般用GFP_HIGHUSER_MOVABLE。

	我們?cè)賮砜匆幌轮苯臃祷靥摂M內(nèi)存的接口函數(shù)。linux-src/include/linux/gfp.h
unsigned?long?__get_free_pages(gfp_t?gfp_mask,?unsigned?int?order);
#define?__get_free_page(gfp_mask)??__get_free_pages((gfp_mask),?0)
#define?__get_dma_pages(gfp_mask,?order)?__get_free_pages((gfp_mask)?|?GFP_DMA,?(order))
unsigned?long?get_zeroed_page(gfp_t?gfp_mask);
void?free_pages(unsigned?long?addr,?unsigned?int?order);
#define?free_page(addr)?free_pages((addr),?0)

	此接口不能分配HIGHMEM中的內(nèi)存，因?yàn)镠IGHMEM中的內(nèi)存不是直接映射到內(nèi)核空間中去的。除此之外這個(gè)接口和前面的沒有區(qū)別，其參數(shù)函數(shù)也跟前面的一樣，就不再贅述了。

	3.1.5 伙伴系統(tǒng)的實(shí)現(xiàn)

	下面我們?cè)賮砜匆幌禄锇橄到y(tǒng)的分配算法。linux-src/mm/page_alloc.c
/*
?*?This?is?the?'heart'?of?the?zoned?buddy?allocator.
?*/
struct?page?*__alloc_pages(gfp_t?gfp,?unsigned?int?order,?int?preferred_nid,
???????nodemask_t?*nodemask)
{
?struct?page?*page;
?
?/*?First?allocation?attempt?*/
?page?=?get_page_from_freelist(alloc_gfp,?order,?alloc_flags,?&ac);
?if?(likely(page))
??goto?out;

?page?=?__alloc_pages_slowpath(alloc_gfp,?order,?&ac);

out:
?return?page;
}

	伙伴系統(tǒng)的所有分配接口最終都會(huì)使用__alloc_pages這個(gè)函數(shù)來進(jìn)行分配。對(duì)這個(gè)函數(shù)進(jìn)行刪減之后，其邏輯也比較簡(jiǎn)單清晰，先使用函數(shù)get_page_from_freelist直接從free_area中進(jìn)行分配，如果分配不到就使用函數(shù) __alloc_pages_slowpath進(jìn)行內(nèi)存回收。內(nèi)存回收的內(nèi)容在下一章里面講。

	3.2 Slab Allocator

	伙伴系統(tǒng)的最小分配粒度是頁面，但是內(nèi)核中有很多大量的同一類型結(jié)構(gòu)體的分配請(qǐng)求，比如說進(jìn)程的結(jié)構(gòu)體task_struct，如果使用伙伴系統(tǒng)來分配顯然不合適，如果自己分配一個(gè)頁面，然后可以分割成多個(gè)task_struct，顯然也很麻煩，于是內(nèi)核中給我們提供了slab分配機(jī)制來滿足這種需求。Slab的基本思想很簡(jiǎn)單，就是自己先從伙伴系統(tǒng)中分配一些頁面，然后把這些頁面切割成一個(gè)個(gè)同樣大小的基本塊，用戶就可以從slab中申請(qǐng)分配一個(gè)同樣大小的內(nèi)存塊了。如果slab中的內(nèi)存不夠用了，它會(huì)再向伙伴系統(tǒng)進(jìn)行申請(qǐng)。不同的slab其基本塊的大小并不相同，內(nèi)核的每個(gè)模塊都要為自己的特定需求分配特定的slab，然后再從這個(gè)slab中分配內(nèi)存。

	剛開始的時(shí)候內(nèi)核中就只有一個(gè)slab，其接口和實(shí)現(xiàn)都叫slab。但是后來內(nèi)核中又出現(xiàn)了兩個(gè)slab實(shí)現(xiàn)，slob和slub。slob是針對(duì)嵌入式系統(tǒng)進(jìn)行優(yōu)化的，slub是針對(duì)內(nèi)存比較多的系統(tǒng)進(jìn)行優(yōu)化的，它們的接口還是slab。由于現(xiàn)在的計(jì)算機(jī)內(nèi)存普遍都比較大，連手機(jī)的的內(nèi)存都6G、8G起步了，所以現(xiàn)在除了嵌入式系統(tǒng)之外，內(nèi)核默認(rèn)使用的都是slub。下面我們畫個(gè)圖看一下它們的關(guān)系。

	

	可以看到Slab在不同的語境下有不同的含義，有時(shí)候指的是整個(gè)Slab機(jī)制，有時(shí)候指的是Slab接口，有時(shí)候指的是Slab實(shí)現(xiàn)。如果我們?cè)谟懻搯栴}的時(shí)候遇到了歧義，可以加上漢語后綴以明確語義。

	3.2.1 Slab接口

	下面我們來看一下slab的接口：linux-src/include/linux/slab.h
struct?kmem_cache?*kmem_cache_create(const?char?*name,?unsigned?int?size,
???unsigned?int?align,?slab_flags_t?flags,
???void?(*ctor)(void?*));
void?kmem_cache_destroy(struct?kmem_cache?*);
void?*kmem_cache_alloc(struct?kmem_cache?*,?gfp_t?flags);
void?kmem_cache_free(struct?kmem_cache?*,?void?*);

	我們?cè)谑褂胹lab時(shí)首先要?jiǎng)?chuàng)建slab，創(chuàng)建slab用的是接口kmem_cache_create，其中最重要的參數(shù)是size，它是基本塊的大小，一般我們都會(huì)傳遞sizeof某個(gè)結(jié)構(gòu)體。創(chuàng)建完slab之后，我們用kmem_cache_alloc從slab中分配內(nèi)存，第一個(gè)參數(shù)指定哪個(gè)是從哪個(gè)slab中分配，第二個(gè)參數(shù)gfp指定如果slab的內(nèi)存不足了如何從伙伴系統(tǒng)中去分配內(nèi)存，gfp的函數(shù)和前面伙伴系統(tǒng)中講的相同，此處就不再贅述了，函數(shù)返回的是一個(gè)指針，其指向的內(nèi)存大小就是slab在創(chuàng)建時(shí)指定的基本塊的大小。當(dāng)我們用完一塊內(nèi)存時(shí)，就要用kmem_cache_free把它還給slab，第一個(gè)參數(shù)指定是哪個(gè)slab，第二個(gè)參數(shù)是我們要返回的內(nèi)存。如果我們想要釋放整個(gè)slab的話，就使用接口kmem_cache_destroy。

	3.2.2 Slab實(shí)現(xiàn)

	暫略

	3.2.3 Slob實(shí)現(xiàn)

	暫略

	3.2.4 Slub實(shí)現(xiàn)

	暫略

	3.3 Kmalloc

	內(nèi)存中還有一些偶發(fā)的零碎的內(nèi)存分配需求，一個(gè)模塊如果僅僅為了分配一次5字節(jié)的內(nèi)存，就去創(chuàng)建一個(gè)slab，那顯然不劃算。為此內(nèi)核創(chuàng)建了一個(gè)統(tǒng)一的零碎內(nèi)存分配器kmalloc，用戶可以直接請(qǐng)求kmalloc分配若干個(gè)字節(jié)的內(nèi)存。Kmalloc底層用的還是slab機(jī)制，kmalloc在啟動(dòng)的時(shí)候會(huì)預(yù)先創(chuàng)建一些不同大小的slab，用戶請(qǐng)求分配任意大小的內(nèi)存，kmalloc都會(huì)去大小剛剛滿足的slab中去分配內(nèi)存。

	下面我們來看一下kmalloc的接口：linux-src/include/linux/slab.h
void?*kmalloc(size_t?size,?gfp_t?flags);
void?kfree(const?void?*);

	可以看到kmalloc的接口很簡(jiǎn)單，使用接口kmalloc就可以分配內(nèi)存，第一個(gè)參數(shù)是你要分配的內(nèi)存大小，第二個(gè)參數(shù)和伙伴系統(tǒng)的參數(shù)是一樣的，這里就不再贅述了，返回值是一個(gè)內(nèi)存指針，用這個(gè)指針就可以訪問分配到的內(nèi)存了。內(nèi)存使用完了之后用kfree進(jìn)行釋放，參數(shù)是剛才分配到的內(nèi)存指針。

	我們以slub實(shí)現(xiàn)為例講一下kmalloc的邏輯。Kmalloc中會(huì)定義一個(gè)全局的slab指針的二維數(shù)組，第一維下標(biāo)代表的是kmalloc的類型，默認(rèn)有四種類型，分別有DMA和NORMAL，這兩個(gè)代表的是gfp中的區(qū)域，還有兩個(gè)是CGROUP和RECLAIM，CGROUP代表的是在memcg中分配內(nèi)存，RECLAIM代表的是可回收內(nèi)存。第二維下標(biāo)代表的是基本塊大小的2的對(duì)數(shù)，不過下標(biāo)0、1、2是例外，有特殊含義。在系統(tǒng)初始化的時(shí)候，會(huì)初始化這個(gè)數(shù)組，創(chuàng)建每一個(gè)slab，下標(biāo)0除外，下標(biāo)1對(duì)應(yīng)的slab的基本塊大小是96，下標(biāo)2對(duì)應(yīng)的slab的基本塊的大小是192。在用kmalloc分配內(nèi)存的時(shí)候，會(huì)先處理特殊情況，當(dāng)size是0的時(shí)候直接返回空指針，當(dāng)size大于8k的時(shí)候會(huì)則直接使用伙伴系統(tǒng)進(jìn)行分配。然后先根據(jù)gfp參數(shù)選擇kmalloc的類型，再根據(jù)size的大小選擇index。如果2^n-1^+1 < size <= 2^n^，則index等于n，但是有特殊情況，當(dāng) 64 < size <= 96時(shí)，index等于1，當(dāng) 128 < size <= 192時(shí)，index等于2。Type和index都確定好之后，就找到了具體的slab了，就可以從這個(gè)slab中分配內(nèi)存了。

	3.4 Vmalloc

	暫略

	3.5 CMA

	暫略

	四、物理內(nèi)存回收

	內(nèi)存作為系統(tǒng)最寶貴的資源，總是不夠用的。當(dāng)內(nèi)存不足的時(shí)候就要對(duì)內(nèi)存進(jìn)行回收了。內(nèi)存回收按照回收時(shí)機(jī)可以分為同步回收和異步回收，同步回收是指在分配內(nèi)存的時(shí)候發(fā)現(xiàn)無法分配到內(nèi)存就進(jìn)行回收，異步回收是指有專門的線程定期進(jìn)行檢測(cè)，如果發(fā)現(xiàn)內(nèi)存不足就進(jìn)行回收。內(nèi)存回收的類型有兩種，一是內(nèi)存規(guī)整，也就是內(nèi)存碎片整理，它不會(huì)增加可用內(nèi)存的總量，但是會(huì)增加連續(xù)可用內(nèi)存的量，二是頁幀回收，它會(huì)把物理頁幀的內(nèi)容寫入到外存中去，然后解除其與虛擬內(nèi)存的映射，這樣可用物理內(nèi)存的量就增加了。內(nèi)存回收的時(shí)機(jī)和類型是正交關(guān)系，同步回收中會(huì)使用內(nèi)存規(guī)整和頁幀回收，異步回收中也會(huì)使用內(nèi)存規(guī)整和頁幀回收。在異步回收中，內(nèi)存規(guī)整有單獨(dú)的線程kcompactd，此類線程一個(gè)node一個(gè)，線程名是[kcompactd/nodeid]，頁幀回收也有單獨(dú)的線程kswapd，此類線程也是一個(gè)node一個(gè)，線程名是[kswapd/nodeid]。在同步回收中，還有一個(gè)大殺器，那就是OOM Killer，OOM是內(nèi)存耗盡的意思，當(dāng)內(nèi)存耗盡，其它所有的內(nèi)存回收方法也回收不到內(nèi)存的時(shí)候，就會(huì)使用這個(gè)大殺器。下面我們畫個(gè)圖來看一下：

	

	4.1 內(nèi)存規(guī)整

	系統(tǒng)運(yùn)行的時(shí)間長了，內(nèi)存一會(huì)兒分配一會(huì)兒釋放，慢慢地可用內(nèi)存就會(huì)變得很碎片化不連續(xù)。雖然總的可用內(nèi)存還不少，但是卻無法分配大塊連續(xù)內(nèi)存，此時(shí)就需要進(jìn)行內(nèi)存規(guī)整了。內(nèi)存規(guī)整是以區(qū)域?yàn)榛締挝?，找到可用移?dòng)的頁幀，把它們都移到同一端，然后連續(xù)可用內(nèi)存的量就增大了。其邏輯如下圖所示：

	

	4.2 頁幀回收

	內(nèi)存規(guī)整只是增加了連續(xù)內(nèi)存的量，但是可用內(nèi)存的量并沒有增加，當(dāng)可用內(nèi)存量不足的時(shí)候就要進(jìn)行頁幀回收。對(duì)于內(nèi)核來說，其虛擬內(nèi)存和物理內(nèi)存的映射關(guān)系是不能解除的，所以必須同時(shí)回收物理內(nèi)存和虛擬內(nèi)存。對(duì)此采取的辦法是讓內(nèi)核的每個(gè)模塊都注冊(cè)shrinker，當(dāng)內(nèi)存緊張時(shí)通過shrinker的回調(diào)函數(shù)通知每個(gè)模塊盡量釋放自己暫時(shí)用不到的內(nèi)存。對(duì)于用戶空間，其虛擬內(nèi)存和物理內(nèi)存的映射關(guān)系是可以解除的，我們可以先把其物理內(nèi)存上的內(nèi)容保存到外存上去，然后再解除映射關(guān)系，這樣其物理內(nèi)存就被回收了，就可以拿做它用了。如果程序后來又用到了這段內(nèi)存，程序訪問其虛擬內(nèi)存的時(shí)候就會(huì)發(fā)生缺頁異常，在缺頁異常里再給它分配物理內(nèi)存，并把其內(nèi)容從外存中加載建立，這樣程序還是能正常運(yùn)行的。進(jìn)程的內(nèi)存頁可以分為兩種類型：一種是文件頁，其內(nèi)容來源于文件，如程序的代碼區(qū)、數(shù)據(jù)區(qū)；一種是匿名頁，沒有內(nèi)容來源，由內(nèi)核直接為其分配內(nèi)存，如進(jìn)程的堆和棧。對(duì)于文件頁，有兩種情況：一種情況是文件頁是clean的，也就是和外存中的內(nèi)容是一樣的，此時(shí)我們可以直接丟棄文件頁，后面用到時(shí)再從外存中加載進(jìn)來；另一種情況是文件頁是dirty的，也就是其經(jīng)歷過修改，和外存中的內(nèi)容不同，此時(shí)要先把文件頁的內(nèi)容寫入到外存中，然后才能回收其內(nèi)存。對(duì)于匿名頁，由于其沒有文件做后備，沒辦法對(duì)其進(jìn)行回收。此時(shí)就需要swap作為匿名頁的后備存儲(chǔ)了，有了swap之后，匿名頁也可以進(jìn)行回收了。Swap是外存中的一片空間，可以是一個(gè)分區(qū)，也可以是文件，具體原理請(qǐng)看下一節(jié)。

	頁幀回收時(shí)如何選擇回收哪些文件頁、匿名頁，不回收哪些文件頁、匿名頁呢，以及文件頁和匿名頁各回收多少比例呢？?jī)?nèi)核把所有的文件頁放到兩個(gè)鏈表上，活躍文件頁和不活躍文件頁，回收的時(shí)候只會(huì)回收不活躍文件頁。內(nèi)核把所有的匿名頁也放到兩個(gè)鏈表上，活躍匿名頁和不活躍匿名頁，回收的時(shí)候只會(huì)回收不活躍匿名頁。有一個(gè)參數(shù)/proc/sys/vm/swappiness控制著匿名頁和文件頁之間的回收比例。

	在回收文件頁和匿名頁的時(shí)候是需要把它們的虛擬內(nèi)存映射給解除掉的。由于一個(gè)物理頁幀可能會(huì)同時(shí)映射到多個(gè)虛擬內(nèi)存上，包括映射到多個(gè)進(jìn)程或者同一個(gè)進(jìn)程的不同地址上，所以我們需要找到一個(gè)物理頁幀所映射的所有虛擬內(nèi)存。如何找到物理內(nèi)存所映射的虛擬內(nèi)存呢，這個(gè)過程就叫做反向映射(rmap)。之所以叫反向映射是因?yàn)檎５挠成涠际菑奶摂M內(nèi)存映射到物理內(nèi)存。

	4.3 交換區(qū)

	暫略

	4.4 OOM Killer

	如果用盡了上述所說的各種辦法還是無法回收到足夠的物理內(nèi)存，那就只能使出殺手锏了，OOM Killer，通過殺死進(jìn)程來回收內(nèi)存。其觸發(fā)點(diǎn)在linux-src/mm/page_alloc.c:__alloc_pages_may_oom，當(dāng)使用各種方法都回收不到內(nèi)存時(shí)會(huì)調(diào)用out_of_memory函數(shù)。

	下面我們來看一下out_of_memory函數(shù)的實(shí)現(xiàn)(經(jīng)過高度刪減)：linux-src/mm/oom_kill.c:out_of_memory
bool?out_of_memory(struct?oom_control?*oc)
{
????select_bad_process(oc);
????oom_kill_process(oc,?"Out?of?memory");
}

	out_of_memory函數(shù)的代碼邏輯還是非常簡(jiǎn)單清晰的，總共有兩步，1.先選擇一個(gè)要?dú)⑺赖倪M(jìn)程，2.殺死它。oom_kill_process函數(shù)的目的很簡(jiǎn)單，但是實(shí)現(xiàn)過程也有點(diǎn)復(fù)雜，這里就不展開分析了，大家可以自行去看一下代碼。我們重點(diǎn)分析一下select_bad_process函數(shù)的邏輯，select_bad_process主要是依靠oom_score來進(jìn)行進(jìn)程選擇的。我們先來看一下和oom_score有關(guān)的三個(gè)文件。

	/proc//oom_score系統(tǒng)計(jì)算出來的oom_score值，只讀文件，取值范圍0 –- 1000，0代表never kill，1000代表aways kill，值越大，進(jìn)程被選中的概率越大。

	/proc//oom_score_adj讓用戶空間調(diào)節(jié)oom_score的接口，root可讀寫，取值范圍 -1000 --- 1000，默認(rèn)為0，若為 -1000，則oom_score加上此值一定小于等于0，從而變成never kill進(jìn)程。OS可以把一些關(guān)鍵的系統(tǒng)進(jìn)程的oom_score_adj設(shè)為-1000，從而避免被oom kill。

	/proc//oom_adj舊的接口文件，為兼容而保留，root可讀寫，取值范圍 -16 — 15，會(huì)被線性映射到oom_score_adj，特殊值 -17代表 OOM_DISABLE。大家盡量不要再用此接口。

	下面我們來分析一下select_bad_process函數(shù)的實(shí)現(xiàn)：
static?void?select_bad_process(struct?oom_control?*oc)
{
?oc->chosen_points?=?LONG_MIN;
?struct?task_struct?*p;

?rcu_read_lock();
?for_each_process(p)
??if?(oom_evaluate_task(p,?oc))
???break;
?rcu_read_unlock();
}

	函數(shù)首先把chosen_points初始化為最小的Long值，這個(gè)值是用來比較所有的oom_score值，最后誰的值最大就選中哪個(gè)進(jìn)程。然后函數(shù)已經(jīng)遍歷所有進(jìn)程，計(jì)算其oom_score，并更新chosen_points和被選中的task，有點(diǎn)類似于選擇排序。我們繼續(xù)看oom_evaluate_task函數(shù)是如何評(píng)估每個(gè)進(jìn)程的函數(shù)。
static?int?oom_evaluate_task(struct?task_struct?*task,?void?*arg)
{
?struct?oom_control?*oc?=?arg;
?long?points;
?if?(oom_unkillable_task(task))
??goto?next;
?/*?p?may?not?have?freeable?memory?in?nodemask?*/
?if?(!is_memcg_oom(oc)?&&?!oom_cpuset_eligible(task,?oc))
??goto?next;
?if?(oom_task_origin(task))?{
??points?=?LONG_MAX;
??goto?select;
?}
?points?=?oom_badness(task,?oc->totalpages);
?if?(points?==?LONG_MIN?||?points?chosen_points)
??goto?next;
select:
?if?(oc->chosen)
??put_task_struct(oc->chosen);
?get_task_struct(task);
?oc->chosen?=?task;
?oc->chosen_points?=?points;
next:
?return?0;
abort:
?if?(oc->chosen)
??put_task_struct(oc->chosen);
?oc->chosen?=?(void?*)-1UL;
?return?1;
}

	此函數(shù)首先會(huì)跳過所有不適合kill的進(jìn)程，如init進(jìn)程、內(nèi)核線程、OOM_DISABLE進(jìn)程等。然后通過select_bad_process算出此進(jìn)程的得分points 也就是oom_score，并和上一次的勝出進(jìn)程進(jìn)行比較，如果小的會(huì)話就會(huì)goto next 返回，如果大的話就會(huì)更新oc->chosen 的task 和 chosen_points 也就是目前最高的oom_score。那么 oom_badness是如何計(jì)算的呢？
long?oom_badness(struct?task_struct?*p,?unsigned?long?totalpages)
{
?long?points;
?long?adj;
?if?(oom_unkillable_task(p))
??return?LONG_MIN;
?p?=?find_lock_task_mm(p);
?if?(!p)
??return?LONG_MIN;
?adj?=?(long)p->signal->oom_score_adj;
?if?(adj?==?OOM_SCORE_ADJ_MIN?||
???test_bit(MMF_OOM_SKIP,?&p->mm->flags)?||
???in_vfork(p))?{
??task_unlock(p);
??return?LONG_MIN;
?}
?points?=?get_mm_rss(p->mm)?+?get_mm_counter(p->mm,?MM_SWAPENTS)?+
??mm_pgtables_bytes(p->mm)?/?PAGE_SIZE;
?task_unlock(p);
?adj?*=?totalpages?/?1000;
?points?+=?adj;
?return?points;
}

	oom_badness首先把unkiller的進(jìn)程也就是init進(jìn)程內(nèi)核線程直接返回 LONG_MIN，這樣它們就不會(huì)被選中而殺死了，這里看好像和前面的檢測(cè)冗余了，但是實(shí)際上這個(gè)函數(shù)還被/proc//oom_score的show函數(shù)調(diào)用用來顯示數(shù)值，所以還是有必要的，這里也說明了一點(diǎn)，oom_score的值是不保留的，每次都是即時(shí)計(jì)算。然后又把oom_score_adj為-1000的進(jìn)程直接也返回LONG_MIN，這樣用戶空間專門設(shè)置的進(jìn)程就不會(huì)被kill了。最后就是計(jì)算oom_score了，計(jì)算方法比較簡(jiǎn)單，就是此進(jìn)程使用的RSS駐留內(nèi)存、頁表、swap之和越大，也就是此進(jìn)程所用的總內(nèi)存越大，oom_score的值就越大，邏輯簡(jiǎn)單直接，誰用的物理內(nèi)存最多就殺誰，這樣就能夠回收更多的物理內(nèi)存，而且使用內(nèi)存最多的進(jìn)程很可能是內(nèi)存泄漏了，所以此算法雖然很簡(jiǎn)單，但是也很合理。

	可能很多人會(huì)覺得這里講的不對(duì)，和自己在網(wǎng)上的看到的邏輯不一樣，那是因?yàn)榫W(wǎng)上有很多講oom_score算法的文章都是基于2.6版本的內(nèi)核講的，那個(gè)算法比較復(fù)雜，會(huì)考慮進(jìn)程的nice值，nice值小的，oom_score會(huì)相應(yīng)地降低，也會(huì)考慮進(jìn)程的運(yùn)行時(shí)間，運(yùn)行時(shí)間越長，oom_score值也會(huì)相應(yīng)地降低，因?yàn)楫?dāng)時(shí)認(rèn)為進(jìn)程運(yùn)行的時(shí)間長消耗內(nèi)存多是合理的。但是這個(gè)算法會(huì)讓那些緩慢內(nèi)存泄漏的進(jìn)程逃脫制裁。因此后來這個(gè)算法就改成現(xiàn)在這樣的了，只考慮誰用的內(nèi)存多就殺誰，簡(jiǎn)潔高效。

	五、物理內(nèi)存壓縮

	暫略

	5.1 ZRAM

	5.2 ZSwap

	5.3 ZCache

	六、虛擬內(nèi)存映射

	開啟分頁內(nèi)存機(jī)制之后，CPU訪問一切內(nèi)存都要通過虛擬內(nèi)存地址訪問，CPU把虛擬內(nèi)存地址發(fā)送給MMU，MMU把虛擬內(nèi)存地址轉(zhuǎn)換為物理內(nèi)存地址，然后再用物理內(nèi)存地址通過MC(內(nèi)存控制器)訪問內(nèi)存。MMU里面有兩個(gè)部件，TLB和PTW。TLB可以意譯地址轉(zhuǎn)換緩存器，它是緩存虛擬地址解析結(jié)果的地方。PTW可以意譯為虛擬地址解析器，它負(fù)責(zé)解析頁表，把虛擬地址轉(zhuǎn)換為物理地址，然后再送去MC進(jìn)行訪問。同時(shí)其轉(zhuǎn)換結(jié)果也會(huì)被送去TLB進(jìn)行緩存，下次再訪問相同虛擬地址的時(shí)候就不用再去解析了，可以直接用緩存的結(jié)果。

	

	6.1 頁表

	虛擬地址映射的基本單位是頁面不是字節(jié)，一個(gè)虛擬內(nèi)存的頁面會(huì)被映射到一個(gè)物理頁幀上。MMU把虛擬地址轉(zhuǎn)換為物理地址的方法是通過查找頁表。一個(gè)頁表的大小也是一個(gè)頁面，4K大小，頁表的內(nèi)容可以看做是頁表項(xiàng)的數(shù)組，一個(gè)頁表項(xiàng)是一個(gè)物理地址，指向一個(gè)物理頁幀，在32位系統(tǒng)上，物理地址是32位也就是4個(gè)字節(jié)，所以一個(gè)頁表有4K/4=1024項(xiàng)，每一項(xiàng)指向一個(gè)物理頁幀，大小是4K，所以一個(gè)頁表可以表達(dá)4M的虛擬內(nèi)存,要想表達(dá)4G的虛擬內(nèi)存空間，需要有1024個(gè)頁表才行，每個(gè)頁表4K，一共需要4M的物理內(nèi)存。4M的物理內(nèi)存看起來好像不大，但是每個(gè)進(jìn)程都需要有4M的物理內(nèi)存做頁表，如果有100個(gè)進(jìn)程，那就需要有400M物理內(nèi)存，這就太浪費(fèi)物理內(nèi)存了，而且大部分時(shí)候，一個(gè)進(jìn)程的大部分虛擬內(nèi)存空間并沒有使用。為此我們可以采取兩級(jí)頁表的方法來進(jìn)行虛擬內(nèi)存映射。在多級(jí)頁表體系中，最后一級(jí)頁表還叫頁表，其它的頁表叫做頁目錄，但是我們有時(shí)候也會(huì)都叫做頁表。對(duì)于兩級(jí)頁表體系，一級(jí)頁表還是一個(gè)頁面，4K大小，每個(gè)頁表項(xiàng)還是4個(gè)字節(jié)，一共有1024項(xiàng)，一級(jí)頁表的頁表項(xiàng)是二級(jí)頁表的物理地址，指向二級(jí)頁表，二級(jí)頁表的內(nèi)容和前面一樣。一級(jí)頁表只有一個(gè)，4K，有1024項(xiàng)，指向1024個(gè)二級(jí)頁表，一個(gè)一級(jí)頁表項(xiàng)也就是一個(gè)二級(jí)頁表可以表達(dá)4M虛擬內(nèi)存，一級(jí)頁表總共能表達(dá)4G虛擬內(nèi)存，此時(shí)所有頁表占用的物理內(nèi)存是4M加4K?？雌饋硎褂枚?jí)頁表好像還多用了4K內(nèi)存，但是在大多數(shù)情況下，很多二級(jí)頁表都用不上，所以不用分配內(nèi)存。如果一個(gè)進(jìn)程只用了8M物理內(nèi)存，那么它只需要一個(gè)一級(jí)頁表和兩個(gè)二級(jí)頁表就行了，一級(jí)頁表中只需要使用兩項(xiàng)指向兩個(gè)二級(jí)頁表，兩個(gè)二級(jí)頁表填充滿，就可以表達(dá)8M虛擬內(nèi)存映射了，此時(shí)總共用了3個(gè)頁表，12K物理內(nèi)存，頁表的內(nèi)存占用大大減少了。所以在32位系統(tǒng)上，采取的是兩級(jí)頁表的方式，每級(jí)的一個(gè)頁表都是1024項(xiàng)，32位虛擬地址正好可以分成三份，10、10、12，第一個(gè)10位可以用于在一級(jí)頁表中尋址，第二個(gè)10位在二級(jí)頁表中尋址，最后12位可以表達(dá)一個(gè)頁面中任何一個(gè)字節(jié)。

	在64位系統(tǒng)上，一個(gè)頁面還是4K大小，一個(gè)頁表還是一個(gè)頁面，但是由于物理地址是64位的，所以一個(gè)頁表項(xiàng)變成了8個(gè)字節(jié)，一個(gè)頁表就只有512個(gè)頁表項(xiàng)了，這樣一個(gè)頁表就只能表達(dá)2M虛擬內(nèi)存了。尋址512個(gè)頁表項(xiàng)只需要9位就夠了。在x86 64上，虛擬地址有64位，但是64位的地址空間實(shí)在是太大了，所以我們只需要用其中一部分就行了。x86 64上有兩種虛擬地址位數(shù)可選，48位和57位，分別對(duì)應(yīng)著四級(jí)頁表和五級(jí)頁表。為啥是四級(jí)頁表和五級(jí)頁表呢？因?yàn)?8=9+9+9+12,57=9+9+9+9+12,12可以尋址一個(gè)頁面內(nèi)的每一個(gè)字節(jié)，9可以尋址一級(jí)頁表中的512個(gè)頁表項(xiàng)。

	Linux內(nèi)核最多支持五級(jí)頁表，在五級(jí)頁表體系中，每一級(jí)頁表分別叫做PGD、P4D、PUD、PMD、PTE。如果頁表不夠五級(jí)的，從第二級(jí)開始依次去掉一級(jí)。

	頁表項(xiàng)是下一級(jí)頁表或者最終頁幀的物理地址，頁表也是一個(gè)頁幀，頁幀的地址都是4K對(duì)齊的，所以頁表項(xiàng)中的物理地址的最后12位一定都是0，既然都是0，那么就沒必要表示出來了，我們就可以把這12位拿來做其它用途了。下面我們來看一下x86的頁表項(xiàng)格式。

	

	這是32位的頁表項(xiàng)格式，其中12-31位是物理地址。

	P，此頁表項(xiàng)是否有效，1代表有效，0代表無效，為0時(shí)其它字段無意義。

	R/W，0代表只讀，1代表可讀寫。

	U/S，0代表內(nèi)核頁表，1代表用戶頁面。

	PWT，Page-level write-through

	PCD，Page-level cache disable

	A，Accessed; indicates whether software has accessed the page

	D，Dirty; indicates whether software has written to the ?page

	PAT，If the PAT is supported, indirectly determines the memory type used to access the page

	G，Global; determines whether the translation is global

	64位系統(tǒng)的頁表項(xiàng)格式和這個(gè)是一樣的，只不過是物理地址擴(kuò)展到了硬件支持的最高物理地址位數(shù)。

	6.2 MMU

	MMU是通過遍歷頁表把虛擬地址轉(zhuǎn)換為物理地址的。其過程如下所示：

	

	CR3是CPU的寄存器，存放的是PGD的物理地址。MMU首先通過CR3獲取PGD的物理地址，然后以虛擬地址的31-22位為index，在PGD中找到相應(yīng)的頁表項(xiàng)，先檢測(cè)頁表項(xiàng)的P是否存在，R/W是否有讀寫權(quán)限，U/S是否有訪問權(quán)限，如果檢測(cè)都通過了，則進(jìn)入下一步，如果沒通過則觸發(fā)缺頁異常。關(guān)于中斷與異常的基本原理請(qǐng)參看《深入理解Linux中斷機(jī)制》。如果檢測(cè)通過了，頁表項(xiàng)的31-12位代表PTE的物理地址，取虛擬地址中的21-12位作為index，在PTE中找到對(duì)應(yīng)的頁表項(xiàng)，也是先各種檢測(cè)，如果沒通過則觸發(fā)缺頁異常。如果通過了，則31-12位代表最終頁幀的物理地址，然后把虛擬地址的11-0位作為頁內(nèi)偏移加上去，就找到了虛擬地址對(duì)應(yīng)的物理地址了，然后送到MC進(jìn)行訪問。64位系統(tǒng)的邏輯和32位是相似的，只不過是多了幾級(jí)頁表而已，就不再贅述了。

	一個(gè)進(jìn)程的所有頁表通過頁表項(xiàng)的指向構(gòu)成了一個(gè)頁表樹，頁表樹的根節(jié)點(diǎn)是PGD，根指針是CR3。頁表樹中所有的地址都是物理地址，MMU在遍歷頁表樹時(shí)使用物理地址可以直接訪問內(nèi)存。一個(gè)頁表只有加入了某個(gè)頁表樹才有意義，孤立的頁表是沒有意義的。每個(gè)進(jìn)程都有一個(gè)頁表樹，切換進(jìn)程就會(huì)切換頁表樹，切換頁表樹的方法是給CR3賦值，讓其指向當(dāng)前進(jìn)程的頁表樹的根節(jié)點(diǎn)也就是PGD。進(jìn)程的虛擬內(nèi)存空間分為兩部分，內(nèi)核空間和用戶空間，所有進(jìn)程的內(nèi)核空間都是共享的，所以所有進(jìn)程的頁表樹根節(jié)點(diǎn)的內(nèi)核子樹都相同。

	

	6.3 缺頁異常

	MMU在解析虛擬內(nèi)存時(shí)如果發(fā)現(xiàn)了讀寫錯(cuò)誤或者權(quán)限錯(cuò)誤或者頁表項(xiàng)無效，就會(huì)觸發(fā)缺頁異常讓內(nèi)核來處理。下面我們來看一下x86的缺頁異常處理的過程。linux-src/arch/x86/mm/fault.c
DEFINE_IDTENTRY_RAW_ERRORCODE(exc_page_fault)
{
?unsigned?long?address?=?read_cr2();
?irqentry_state_t?state;

?prefetchw(¤t->mm->mmap_lock);

?if?(kvm_handle_async_pf(regs,?(u32)address))
??return;

?state?=?irqentry_enter(regs);

?instrumentation_begin();
?handle_page_fault(regs,?error_code,?address);
?instrumentation_end();

?irqentry_exit(regs,?state);
}

static?__always_inline?void
handle_page_fault(struct?pt_regs?*regs,?unsigned?long?error_code,
?????????unsigned?long?address)
{
?trace_page_fault_entries(regs,?error_code,?address);

?if?(unlikely(kmmio_fault(regs,?address)))
??return;

?/*?Was?the?fault?on?kernel-controlled?part?of?the?address?space??*/
?if?(unlikely(fault_in_kernel_space(address)))?{
??do_kern_addr_fault(regs,?error_code,?address);
?}?else?{
??do_user_addr_fault(regs,?error_code,?address);
??/*
???*?User?address?page?fault?handling?might?have?reenabled
???*?interrupts.?Fixing?up?all?potential?exit?points?of
???*?do_user_addr_fault()?and?its?leaf?functions?is?just?not
???*?doable?w/o?creating?an?unholy?mess?or?turning?the?code
???*?upside?down.
???*/
??local_irq_disable();
?}
}

static?void
do_kern_addr_fault(struct?pt_regs?*regs,?unsigned?long?hw_error_code,
?????unsigned?long?address)
{
?WARN_ON_ONCE(hw_error_code?&?X86_PF_PK);

#ifdef?CONFIG_X86_32
?if?(!(hw_error_code?&?(X86_PF_RSVD?|?X86_PF_USER?|?X86_PF_PROT)))?{
??if?(vmalloc_fault(address)?>=?0)
???return;
?}
#endif

?if?(is_f00f_bug(regs,?hw_error_code,?address))
??return;

?/*?Was?the?fault?spurious,?caused?by?lazy?TLB?invalidation??*/
?if?(spurious_kernel_fault(hw_error_code,?address))
??return;

?/*?kprobes?don't?want?to?hook?the?spurious?faults:?*/
?if?(WARN_ON_ONCE(kprobe_page_fault(regs,?X86_TRAP_PF)))
??return;

?bad_area_nosemaphore(regs,?hw_error_code,?address);
}

static?inline
void?do_user_addr_fault(struct?pt_regs?*regs,
???unsigned?long?error_code,
???unsigned?long?address)
{
?struct?vm_area_struct?*vma;
?struct?task_struct?*tsk;
?struct?mm_struct?*mm;
?vm_fault_t?fault;
?unsigned?int?flags?=?FAULT_FLAG_DEFAULT;

?tsk?=?current;
?mm?=?tsk->mm;

?if?(unlikely((error_code?&?(X86_PF_USER?|?X86_PF_INSTR))?==?X86_PF_INSTR))?{
??/*
???*?Whoops,?this?is?kernel?mode?code?trying?to?execute?from
???*?user?memory.??Unless?this?is?AMD?erratum?#93,?which
???*?corrupts?RIP?such?that?it?looks?like?a?user?address,
???*?this?is?unrecoverable.??Don't?even?try?to?look?up?the
???*?VMA?or?look?for?extable?entries.
???*/
??if?(is_errata93(regs,?address))
???return;

??page_fault_oops(regs,?error_code,?address);
??return;
?}

?/*?kprobes?don't?want?to?hook?the?spurious?faults:?*/
?if?(WARN_ON_ONCE(kprobe_page_fault(regs,?X86_TRAP_PF)))
??return;

?/*
??*?Reserved?bits?are?never?expected?to?be?set?on
??*?entries?in?the?user?portion?of?the?page?tables.
??*/
?if?(unlikely(error_code?&?X86_PF_RSVD))
??pgtable_bad(regs,?error_code,?address);

?/*
??*?If?SMAP?is?on,?check?for?invalid?kernel?(supervisor)?access?to?user
??*?pages?in?the?user?address?space.??The?odd?case?here?is?WRUSS,
??*?which,?according?to?the?preliminary?documentation,?does?not?respect
??*?SMAP?and?will?have?the?USER?bit?set?so,?in?all?cases,?SMAP
??*?enforcement?appears?to?be?consistent?with?the?USER?bit.
??*/
?if?(unlikely(cpu_feature_enabled(X86_FEATURE_SMAP)?&&
???????!(error_code?&?X86_PF_USER)?&&
???????!(regs->flags?&?X86_EFLAGS_AC)))?{
??/*
???*?No?extable?entry?here.??This?was?a?kernel?access?to?an
???*?invalid?pointer.??get_kernel_nofault()?will?not?get?here.
???*/
??page_fault_oops(regs,?error_code,?address);
??return;
?}

?/*
??*?If?we're?in?an?interrupt,?have?no?user?context?or?are?running
??*?in?a?region?with?pagefaults?disabled?then?we?must?not?take?the?fault
??*/
?if?(unlikely(faulthandler_disabled()?||?!mm))?{
??bad_area_nosemaphore(regs,?error_code,?address);
??return;
?}

?/*
??*?It's?safe?to?allow?irq's?after?cr2?has?been?saved?and?the
??*?vmalloc?fault?has?been?handled.
??*
??*?User-mode?registers?count?as?a?user?access?even?for?any
??*?potential?system?fault?or?CPU?buglet:
??*/
?if?(user_mode(regs))?{
??local_irq_enable();
??flags?|=?FAULT_FLAG_USER;
?}?else?{
??if?(regs->flags?&?X86_EFLAGS_IF)
???local_irq_enable();
?}

?perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS,?1,?regs,?address);

?if?(error_code?&?X86_PF_WRITE)
??flags?|=?FAULT_FLAG_WRITE;
?if?(error_code?&?X86_PF_INSTR)
??flags?|=?FAULT_FLAG_INSTRUCTION;

#ifdef?CONFIG_X86_64
?/*
??*?Faults?in?the?vsyscall?page?might?need?emulation.??The
??*?vsyscall?page?is?at?a?high?address?(>PAGE_OFFSET),?but?is
??*?considered?to?be?part?of?the?user?address?space.
??*
??*?The?vsyscall?page?does?not?have?a?"real"?VMA,?so?do?this
??*?emulation?before?we?go?searching?for?VMAs.
??*
??*?PKRU?never?rejects?instruction?fetches,?so?we?don't?need
??*?to?consider?the?PF_PK?bit.
??*/
?if?(is_vsyscall_vaddr(address))?{
??if?(emulate_vsyscall(error_code,?regs,?address))
???return;
?}
#endif

?/*
??*?Kernel-mode?access?to?the?user?address?space?should?only?occur
??*?on?well-defined?single?instructions?listed?in?the?exception
??*?tables.??But,?an?erroneous?kernel?fault?occurring?outside?one?of
??*?those?areas?which?also?holds?mmap_lock?might?deadlock?attempting
??*?to?validate?the?fault?against?the?address?space.
??*
??*?Only?do?the?expensive?exception?table?search?when?we?might?be?at
??*?risk?of?a?deadlock.??This?happens?if?we
??*?1.?Failed?to?acquire?mmap_lock,?and
??*?2.?The?access?did?not?originate?in?userspace.
??*/
?if?(unlikely(!mmap_read_trylock(mm)))?{
??if?(!user_mode(regs)?&&?!search_exception_tables(regs->ip))?{
???/*
????*?Fault?from?code?in?kernel?from
????*?which?we?do?not?expect?faults.
????*/
???bad_area_nosemaphore(regs,?error_code,?address);
???return;
??}
retry:
??mmap_read_lock(mm);
?}?else?{
??/*
???*?The?above?down_read_trylock()?might?have?succeeded?in
???*?which?case?we'll?have?missed?the?might_sleep()?from
???*?down_read():
???*/
??might_sleep();
?}

?vma?=?find_vma(mm,?address);
?if?(unlikely(!vma))?{
??bad_area(regs,?error_code,?address);
??return;
?}
?if?(likely(vma->vm_start?<=?address))
??goto?good_area;
?if?(unlikely(!(vma->vm_flags?&?VM_GROWSDOWN)))?{
??bad_area(regs,?error_code,?address);
??return;
?}
?if?(unlikely(expand_stack(vma,?address)))?{
??bad_area(regs,?error_code,?address);
??return;
?}

?/*
??*?Ok,?we?have?a?good?vm_area?for?this?memory?access,?so
??*?we?can?handle?it..
??*/
good_area:
?if?(unlikely(access_error(error_code,?vma)))?{
??bad_area_access_error(regs,?error_code,?address,?vma);
??return;
?}

?/*
??*?If?for?any?reason?at?all?we?couldn't?handle?the?fault,
??*?make?sure?we?exit?gracefully?rather?than?endlessly?redo
??*?the?fault.??Since?we?never?set?FAULT_FLAG_RETRY_NOWAIT,?if
??*?we?get?VM_FAULT_RETRY?back,?the?mmap_lock?has?been?unlocked.
??*
??*?Note?that?handle_userfault()?may?also?release?and?reacquire?mmap_lock
??*?(and?not?return?with?VM_FAULT_RETRY),?when?returning?to?userland?to
??*?repeat?the?page?fault?later?with?a?VM_FAULT_NOPAGE?retval
??*?(potentially?after?handling?any?pending?signal?during?the?return?to
??*?userland).?The?return?to?userland?is?identified?whenever
??*?FAULT_FLAG_USER|FAULT_FLAG_KILLABLE?are?both?set?in?flags.
??*/
?fault?=?handle_mm_fault(vma,?address,?flags,?regs);

?if?(fault_signal_pending(fault,?regs))?{
??/*
???*?Quick?path?to?respond?to?signals.??The?core?mm?code
???*?has?unlocked?the?mm?for?us?if?we?get?here.
???*/
??if?(!user_mode(regs))
???kernelmode_fixup_or_oops(regs,?error_code,?address,
???????SIGBUS,?BUS_ADRERR,
???????ARCH_DEFAULT_PKEY);
??return;
?}

?/*
??*?If?we?need?to?retry?the?mmap_lock?has?already?been?released,
??*?and?if?there?is?a?fatal?signal?pending?there?is?no?guarantee
??*?that?we?made?any?progress.?Handle?this?case?first.
??*/
?if?(unlikely((fault?&?VM_FAULT_RETRY)?&&
???????(flags?&?FAULT_FLAG_ALLOW_RETRY)))?{
??flags?|=?FAULT_FLAG_TRIED;
??goto?retry;
?}

?mmap_read_unlock(mm);
?if?(likely(!(fault?&?VM_FAULT_ERROR)))
??return;

?if?(fatal_signal_pending(current)?&&?!user_mode(regs))?{
??kernelmode_fixup_or_oops(regs,?error_code,?address,
??????0,?0,?ARCH_DEFAULT_PKEY);
??return;
?}

?if?(fault?&?VM_FAULT_OOM)?{
??/*?Kernel?mode??Handle?exceptions?or?die:?*/
??if?(!user_mode(regs))?{
???kernelmode_fixup_or_oops(regs,?error_code,?address,
???????SIGSEGV,?SEGV_MAPERR,
???????ARCH_DEFAULT_PKEY);
???return;
??}

??/*
???*?We?ran?out?of?memory,?call?the?OOM?killer,?and?return?the
???*?userspace?(which?will?retry?the?fault,?or?kill?us?if?we?got
???*?oom-killed):
???*/
??pagefault_out_of_memory();
?}?else?{
??if?(fault?&?(VM_FAULT_SIGBUS|VM_FAULT_HWPOISON|
????????VM_FAULT_HWPOISON_LARGE))
???do_sigbus(regs,?error_code,?address,?fault);
??else?if?(fault?&?VM_FAULT_SIGSEGV)
???bad_area_nosemaphore(regs,?error_code,?address);
??else
???BUG();
?}
}

	缺頁異常首先從CR2寄存器中讀取發(fā)生異常的虛擬內(nèi)存地址。然后根據(jù)此地址是在內(nèi)核空間還是在用戶空間，分別調(diào)用do_kern_addr_fault和do_user_addr_fault來處理。使用vmalloc時(shí)會(huì)出現(xiàn)內(nèi)核空間的缺頁異常。用戶空間地址的缺頁異常在做完各種檢測(cè)處理之后會(huì)調(diào)用所有架構(gòu)都通用的函數(shù)handle_mm_fault來處理。下面我們來看一下這個(gè)函數(shù)是怎么處理的。linux-src/mm/memory.c
vm_fault_t?handle_mm_fault(struct?vm_area_struct?*vma,?unsigned?long?address,
??????unsigned?int?flags,?struct?pt_regs?*regs)
{
?vm_fault_t?ret;

?__set_current_state(TASK_RUNNING);

?if?(!arch_vma_access_permitted(vma,?flags?&?FAULT_FLAG_WRITE,
?????????flags?&?FAULT_FLAG_INSTRUCTION,
?????????flags?&?FAULT_FLAG_REMOTE))
??return?VM_FAULT_SIGSEGV;

?if?(flags?&?FAULT_FLAG_USER)
??mem_cgroup_enter_user_fault();

?if?(unlikely(is_vm_hugetlb_page(vma)))
??ret?=?hugetlb_fault(vma->vm_mm,?vma,?address,?flags);
?else
??ret?=?__handle_mm_fault(vma,?address,?flags);

?return?ret;
}

static?vm_fault_t?__handle_mm_fault(struct?vm_area_struct?*vma,
??unsigned?long?address,?unsigned?int?flags)
{
?struct?vm_fault?vmf?=?{
??.vma?=?vma,
??.address?=?address?&?PAGE_MASK,
??.flags?=?flags,
??.pgoff?=?linear_page_index(vma,?address),
??.gfp_mask?=?__get_fault_gfp_mask(vma),
?};
?unsigned?int?dirty?=?flags?&?FAULT_FLAG_WRITE;
?struct?mm_struct?*mm?=?vma->vm_mm;
?pgd_t?*pgd;
?p4d_t?*p4d;
?vm_fault_t?ret;

?pgd?=?pgd_offset(mm,?address);
?p4d?=?p4d_alloc(mm,?pgd,?address);
?if?(!p4d)
??return?VM_FAULT_OOM;

?vmf.pud?=?pud_alloc(mm,?p4d,?address);

?return?handle_pte_fault(&vmf);
}

static?vm_fault_t?handle_pte_fault(struct?vm_fault?*vmf)
{
?pte_t?entry;

?if?(!vmf->pte)?{
??if?(vma_is_anonymous(vmf->vma))
???return?do_anonymous_page(vmf);
??else
???return?do_fault(vmf);
?}

?if?(!pte_present(vmf->orig_pte))
??return?do_swap_page(vmf);

?if?(pte_protnone(vmf->orig_pte)?&&?vma_is_accessible(vmf->vma))
??return?do_numa_page(vmf);

?vmf->ptl?=?pte_lockptr(vmf->vma->vm_mm,?vmf->pmd);
?spin_lock(vmf->ptl);
?entry?=?vmf->orig_pte;
?if?(unlikely(!pte_same(*vmf->pte,?entry)))?{
??update_mmu_tlb(vmf->vma,?vmf->address,?vmf->pte);
??goto?unlock;
?}
?if?(vmf->flags?&?FAULT_FLAG_WRITE)?{
??if?(!pte_write(entry))
???return?do_wp_page(vmf);
??entry?=?pte_mkdirty(entry);
?}
?entry?=?pte_mkyoung(entry);
?if?(ptep_set_access_flags(vmf->vma,?vmf->address,?vmf->pte,?entry,
????vmf->flags?&?FAULT_FLAG_WRITE))?{
??update_mmu_cache(vmf->vma,?vmf->address,?vmf->pte);
?}?else?{
??if?(vmf->flags?&?FAULT_FLAG_TRIED)
???goto?unlock;
??if?(vmf->flags?&?FAULT_FLAG_WRITE)
???flush_tlb_fix_spurious_fault(vmf->vma,?vmf->address);
?}
unlock:
?pte_unmap_unlock(vmf->pte,?vmf->ptl);
?return?0;
}

static?vm_fault_t?do_fault(struct?vm_fault?*vmf)
{
?struct?vm_area_struct?*vma?=?vmf->vma;
?struct?mm_struct?*vm_mm?=?vma->vm_mm;
?vm_fault_t?ret;

?if?(!vma->vm_ops->fault)?{
??if?(unlikely(!pmd_present(*vmf->pmd)))
???ret?=?VM_FAULT_SIGBUS;
??else?{
???vmf->pte?=?pte_offset_map_lock(vmf->vma->vm_mm,
?????????????vmf->pmd,
?????????????vmf->address,
?????????????&vmf->ptl);
???if?(unlikely(pte_none(*vmf->pte)))
????ret?=?VM_FAULT_SIGBUS;
???else
????ret?=?VM_FAULT_NOPAGE;

???pte_unmap_unlock(vmf->pte,?vmf->ptl);
??}
?}?else?if?(!(vmf->flags?&?FAULT_FLAG_WRITE))
??ret?=?do_read_fault(vmf);
?else?if?(!(vma->vm_flags?&?VM_SHARED))
??ret?=?do_cow_fault(vmf);
?else
??ret?=?do_shared_fault(vmf);

?if?(vmf->prealloc_pte)?{
??pte_free(vm_mm,?vmf->prealloc_pte);
??vmf->prealloc_pte?=?NULL;
?}
?return?ret;
}

	可以看到handle_mm_fault最終會(huì)調(diào)用handle_pte_fault進(jìn)行處理。在handle_pte_fault中，會(huì)根據(jù)缺頁的內(nèi)存的類型進(jìn)行相應(yīng)的處理。

	七、虛擬內(nèi)存空間

	CPU開啟了分頁內(nèi)存機(jī)制之后，就只能通過虛擬內(nèi)存來訪問內(nèi)存了。內(nèi)核通過構(gòu)建頁表樹來創(chuàng)建虛擬內(nèi)存空間，一個(gè)頁表樹對(duì)應(yīng)一個(gè)虛擬內(nèi)存空間。虛擬內(nèi)存空間又分為兩部分，內(nèi)核空間和用戶空間。所有的頁表樹都共享內(nèi)核空間，它們內(nèi)核頁表子樹是相同的。內(nèi)核空間和用戶空間不僅在數(shù)量上不同，在權(quán)限上不同，在構(gòu)建方式上也不同。內(nèi)核空間在系統(tǒng)全局都只有一個(gè)，不僅在UP上是如此，在SMP上也是只有一個(gè)，多個(gè)CPU共享同一個(gè)內(nèi)核空間。內(nèi)核空間是特權(quán)空間，可以執(zhí)行所有的操作，也可以訪問用戶空間。用戶空間是非特權(quán)空間，很多操作不能做，也不能隨意訪問內(nèi)核，唯一能訪問內(nèi)核的方式就是通過系統(tǒng)調(diào)用。內(nèi)核空間和用戶空間最大的不同是構(gòu)建方式。內(nèi)核空間是在系統(tǒng)啟動(dòng)時(shí)就構(gòu)建好的，是完整構(gòu)建的，物理內(nèi)存和虛擬內(nèi)存是直接一次就映射好的，而且是不會(huì)銷毀的，因?yàn)橄到y(tǒng)運(yùn)行著內(nèi)核就要一直存在。用戶空間是在創(chuàng)建進(jìn)程時(shí)構(gòu)建的，但是并沒有完整構(gòu)建，虛擬內(nèi)存到物理內(nèi)存的映射是隨著進(jìn)程的運(yùn)行通過觸發(fā)缺頁異常一步一步構(gòu)建的，而且在內(nèi)存回收時(shí)還有可能被解除映射，最后隨著進(jìn)程的死亡，用戶空間還會(huì)被銷毀。下面我們看個(gè)圖：

	

	這個(gè)圖是在講進(jìn)程調(diào)度時(shí)畫的圖，但是也能表明內(nèi)核空間和用戶空間的關(guān)系。下面我們?cè)賮砜匆幌聠蝹€(gè)進(jìn)程角度下內(nèi)核空間與用戶空間的關(guān)系圖。

	

	在32位系統(tǒng)上默認(rèn)是內(nèi)核占據(jù)上面1G虛擬空間，進(jìn)程占據(jù)下面3G虛擬空間，有config選項(xiàng)可以選擇其它比列，所有CPU架構(gòu)都是如此。在64位系統(tǒng)上，由于64位的地址空間實(shí)在是太大了，Linux并沒有使用全部的虛擬內(nèi)存空間，而是只使用其中一部分位數(shù)。使用的方法是把用戶空間的高位補(bǔ)0，內(nèi)核空間的高位補(bǔ)1，這樣從64位地址空間的角度來看就是只使用了兩段，中間留空，方便以后往中間擴(kuò)展。中間留空的是非法內(nèi)存空間，不能使用。具體使用多少位，高位如何補(bǔ)0，不同架構(gòu)的選擇是不同的。ARM64在4K頁面大小的情況下有39位和48位兩種虛擬地址空間的選擇。X86 64有48位和57位兩種虛擬地址空間的選擇。ARM64是內(nèi)核空間和用戶空間都有這么多的地址空間，x86 64是內(nèi)核空間和用戶空間平分這么多的地址空間，上圖中的大小也可以反應(yīng)出這一點(diǎn)。

	7.1 內(nèi)核空間

	系統(tǒng)在剛啟動(dòng)時(shí)肯定不可能直接就運(yùn)行在虛擬內(nèi)存之上。系統(tǒng)是先運(yùn)行在物理內(nèi)存上，然后去建立一部分恒等映射，恒等映射就是虛擬內(nèi)存的地址和物理內(nèi)存的地址相同的映射。恒等映射的范圍不是要覆蓋全部的物理內(nèi)存，而是夠當(dāng)時(shí)內(nèi)核的運(yùn)行就可以了。恒等映射建立好之后就會(huì)開啟分頁機(jī)制，此時(shí)CPU就運(yùn)行在虛擬內(nèi)存上了。然后內(nèi)核再進(jìn)一步構(gòu)建頁表，把內(nèi)核映射到其規(guī)定好的地方。最后內(nèi)核跳轉(zhuǎn)到其目標(biāo)虛擬地址的地方運(yùn)行，并把之前的恒等映射取消掉，現(xiàn)在內(nèi)核就完全運(yùn)行在虛擬內(nèi)存上了。

	由于內(nèi)核是最先運(yùn)行的，內(nèi)核會(huì)把物理內(nèi)存線性映射到自己的空間中去，而且是要把所有的物理內(nèi)存都映射到內(nèi)核空間。如果內(nèi)核沒有把全部物理內(nèi)存都映射到內(nèi)核空間，那不是因?yàn)椴幌耄且驗(yàn)樽霾坏?。在x86 32上，內(nèi)核空間只有1G，扣除一些其它用途保留的128M空間，內(nèi)核能線性映射的空間只有896M，而物理內(nèi)存可以多達(dá)4G，是沒法都映射到內(nèi)核空間的。所以內(nèi)核會(huì)把小于896M的物理內(nèi)存都映射到內(nèi)核空間，大于896M的物理內(nèi)存作為高端內(nèi)存，可以動(dòng)態(tài)映射到內(nèi)核的vmalloc區(qū)。對(duì)于64位系統(tǒng)，就不存在這個(gè)煩惱了，虛擬內(nèi)存空間遠(yuǎn)遠(yuǎn)大于物理內(nèi)存的數(shù)量，所以內(nèi)核會(huì)一下子把全部物理內(nèi)存都映射到內(nèi)核空間。

	大家在這里可能有兩個(gè)誤解：一是認(rèn)為物理內(nèi)存映射就代表使用，不使用就不會(huì)映射，這是不對(duì)的，使用時(shí)肯定要映射，但是映射了不代表在使用，映射了可以先放在那，只有被內(nèi)存分配器分配出去的才算是被使用；二是物理內(nèi)存只會(huì)被內(nèi)核空間或者用戶空間兩者之一映射，誰使用了就映射到誰的空間中去，這也是不對(duì)的，對(duì)于用戶空間，只有其使用了物理內(nèi)存才會(huì)去映射，但是對(duì)于內(nèi)核空間，內(nèi)核空間是管理者，它把所有物理內(nèi)存都映射到自己的空間比較方便管理，而且映射了不代表使用。

	64位和32位還有一個(gè)很大的不同。32位上是把小于896M的物理內(nèi)存都線性映射到從3G開始的內(nèi)核空間中去，32位上只有一個(gè)線性映射區(qū)間。64位上有兩個(gè)線性映射區(qū)間，一是把內(nèi)核代碼和數(shù)據(jù)所在的物理內(nèi)存映射到一個(gè)固定的地址區(qū)間中去，二是把所有物理內(nèi)存都映射到某一段內(nèi)存區(qū)間中去，顯然內(nèi)核本身所占用的物理內(nèi)存被映射了兩次。下面我們畫圖來看一看內(nèi)核空間的布局。

	

	32位的內(nèi)核空間布局比較簡(jiǎn)單，前896M是直接映射區(qū)，后面是8M的的隔離區(qū)，然后是大約100多M的vmalloc區(qū)，再后面是持久映射區(qū)和固定映射區(qū)，其位置和大小是由宏決定的。

	64位的內(nèi)核空間布局比較復(fù)雜，而且不同的架構(gòu)之間差異非常大，我們以x86 64 48位虛擬地址為例說一下。圖中一列畫不下，分成了兩列，我們從48位-1看起，首先是由一個(gè)8T的空洞，然后是LDT remap，然后是直接映射區(qū)有64T，用來映射所有的物理內(nèi)存，目前來說對(duì)于絕大部分計(jì)算機(jī)都?jí)蛴昧?，然后?.5T的空洞，然后是vmalloc和ioremap區(qū)有32T，然后是1T的空洞，然后是vmemmap區(qū)有1T，vmemmap就是我們前面所講的所有頁面描述符的數(shù)組，然后是1T的空洞，然后是KASAN的影子內(nèi)存有16T，緊接著再看48位-2，首先是2T的空洞，然后是cpu_entry_area，然后是0.5T的空洞，然后是%esp fixup stack，然后是444G的空洞，然后是EFI的映射區(qū)域，然后是2T的空洞，然后是內(nèi)核的映射區(qū)有512M，然后是ko的映射區(qū)有1520M，然后是fixmap和vsyscall，最后是2M的空洞。如果開啟了kaslr，內(nèi)核和映射區(qū)會(huì)增加512M，相應(yīng)的ko的映射區(qū)會(huì)減少512M。

	64位的內(nèi)核空間中有直接映射區(qū)和內(nèi)核映射區(qū)兩個(gè)線性映射區(qū)，這兩個(gè)區(qū)域都是線性映射，只不過是映射的起點(diǎn)不同。為什么要把內(nèi)核再單獨(dú)映射一遍呢？而且既然直接映射區(qū)已經(jīng)把所有的物理內(nèi)存都映射一遍了，那么為什么還有這么多的內(nèi)存映射區(qū)呢？直接映射區(qū)的存在是為了方便管理物理內(nèi)存，因?yàn)樗臀锢韮?nèi)存只差一個(gè)固定值。各種其它映射區(qū)的存在是為了方便內(nèi)核的運(yùn)行和使用。比如vmalloc區(qū)是為了方便進(jìn)行隨機(jī)映射，當(dāng)內(nèi)存碎片化比較嚴(yán)重，我們需要的內(nèi)存又不要求物理上必須連續(xù)時(shí)，就可以使用vmalloc，它能把物理上不連續(xù)的內(nèi)存映射到連續(xù)的虛擬內(nèi)存上。vmemmap區(qū)域是為了在物理內(nèi)存有較大空洞時(shí)，又能夠使得memmap在虛擬內(nèi)存上看起來是個(gè)完整的數(shù)組。這些都方便了內(nèi)核的操作。

	對(duì)比32位和64位的虛擬內(nèi)存空間可以發(fā)現(xiàn)，空間大了就是比較闊綽，動(dòng)不動(dòng)就來個(gè)1T、2T的空洞。

	7.2 用戶空間

	用戶空間的邏輯和內(nèi)核空間就完全不同了。首先用戶空間是進(jìn)程創(chuàng)建時(shí)動(dòng)態(tài)創(chuàng)建的。其次，對(duì)于內(nèi)核，虛擬內(nèi)存和物理內(nèi)存是提前映射好的，就算是vmalloc，也是分配時(shí)就映射好的，對(duì)于用戶空間，物理內(nèi)存的分配和虛擬內(nèi)存的分配是割裂的，用戶空間總是先分配虛擬內(nèi)存不分配物理內(nèi)存，物理內(nèi)存總是拖到最后一刻才去分配。而且對(duì)于進(jìn)程本身來說，它只能分配虛擬內(nèi)存，物理內(nèi)存的分配對(duì)它來說是不可見的，或者說是透明的。當(dāng)進(jìn)程去使用某一個(gè)虛擬內(nèi)存時(shí)如果發(fā)現(xiàn)還沒有分配物理內(nèi)存則會(huì)觸發(fā)缺頁異常，此時(shí)才會(huì)去分配物理內(nèi)存并映射上，然后再去重新執(zhí)行剛才的指令，這一切對(duì)進(jìn)程來說都是透明的，進(jìn)程感知不到。

	管理進(jìn)程空間的結(jié)構(gòu)體是mm_struct，我們先來看一下(代碼有所刪減)：linux-src/include/linux/mm_types.h
struct?mm_struct?{
?struct?{
??struct?vm_area_struct?*mmap;??/*?list?of?VMAs?*/
??struct?rb_root?mm_rb;
??u64?vmacache_seqnum;???????????????????/*?per-thread?vmacache?*/
#ifdef?CONFIG_MMU
??unsigned?long?(*get_unmapped_area)?(struct?file?*filp,
????unsigned?long?addr,?unsigned?long?len,
????unsigned?long?pgoff,?unsigned?long?flags);
#endif
??unsigned?long?mmap_base;?/*?base?of?mmap?area?*/
??unsigned?long?mmap_legacy_base;?/*?base?of?mmap?area?in?bottom-up?allocations?*/

??unsigned?long?task_size;?/*?size?of?task?vm?space?*/
??unsigned?long?highest_vm_end;?/*?highest?vma?end?address?*/
??pgd_t?*?pgd;

??atomic_t?mm_users;
??atomic_t?mm_count;

#ifdef?CONFIG_MMU
??atomic_long_t?pgtables_bytes;?/*?PTE?page?table?pages?*/
#endif
??int?map_count;???/*?number?of?VMAs?*/
??spinlock_t?page_table_lock;?
??struct?rw_semaphore?mmap_lock;
??struct?list_head?mmlist;?

??unsigned?long?hiwater_rss;?/*?High-watermark?of?RSS?usage?*/
??unsigned?long?hiwater_vm;??/*?High-water?virtual?memory?usage?*/
??unsigned?long?total_vm;????/*?Total?pages?mapped?*/
??unsigned?long?locked_vm;???/*?Pages?that?have?PG_mlocked?set?*/
??atomic64_t????pinned_vm;???/*?Refcount?permanently?increased?*/
??unsigned?long?data_vm;????/*?VM_WRITE?&?~VM_SHARED?&?~VM_STACK?*/
??unsigned?long?exec_vm;????/*?VM_EXEC?&?~VM_WRITE?&?~VM_STACK?*/
??unsigned?long?stack_vm;????/*?VM_STACK?*/
??unsigned?long?def_flags;

??unsigned?long?start_code,?end_code,?start_data,?end_data;
??unsigned?long?start_brk,?brk,?start_stack;
??unsigned?long?arg_start,?arg_end,?env_start,?env_end;
??unsigned?long?saved_auxv[AT_VECTOR_SIZE];?/*?for?/proc/PID/auxv?*/
?
??struct?mm_rss_stat?rss_stat;
??struct?linux_binfmt?*binfmt;
??mm_context_t?context;
??unsigned?long?flags;?/*?Must?use?atomic?bitops?to?access?*/
??struct?core_state?*core_state;?/*?coredumping?support?*/
??struct?user_namespace?*user_ns;

??/*?store?ref?to?file?/proc//exe?symlink?points?to?*/
??struct?file?__rcu?*exe_file;

?}?__randomize_layout;

?unsigned?long?cpu_bitmap[];
};

	可以看到mm_struct有很多管理數(shù)據(jù)，其中最重要的兩個(gè)是mmap和pgd，它們一個(gè)代表虛擬內(nèi)存的分配情況，一個(gè)代表物理內(nèi)存的分配情況。pgd就是我們前面所說的頁表樹的根指針，當(dāng)要運(yùn)行我們的進(jìn)程時(shí)就需要把pgd寫到CR3上，這樣MMU用我們頁表樹來解析虛擬地址就能訪問到我們的物理內(nèi)存了。不過pgd的值是虛擬內(nèi)存，CR3需要物理內(nèi)存，所以把pgd寫到CR3上時(shí)還需要把pgd轉(zhuǎn)化為物理地址。mmap是vm_area_struct(vma)的鏈表，它代表的是用戶空間虛擬內(nèi)存的分配情況。用戶空間只能分配虛擬內(nèi)存，物理內(nèi)存的分配是自動(dòng)的透明的。用戶空間想要分配虛擬內(nèi)存，最終的唯一的方法就是調(diào)用函數(shù)mmap來生成一個(gè)vma，有了vma就代表虛擬內(nèi)存分配了，vma會(huì)記錄虛擬內(nèi)存的起點(diǎn)、大小和權(quán)限等信息。有了vma，缺頁異常在處理時(shí)就有了依據(jù)。如果造成缺頁異常的虛擬地址不再任何vma的區(qū)間中，則說明這是一個(gè)非法的虛擬地址，缺頁異常就會(huì)給進(jìn)程發(fā)SIGSEGV。如果異常地址在某個(gè)vma區(qū)間中并且權(quán)限也對(duì)的話，那么說明這個(gè)虛擬地址進(jìn)程已經(jīng)分配了，是個(gè)合法的虛擬地址，此時(shí)缺頁異常就會(huì)去分配物理內(nèi)存并映射到虛擬內(nèi)存上。

	調(diào)用函數(shù)mmap生成vma的方式有兩種，一是內(nèi)核為進(jìn)程調(diào)用，就是在內(nèi)核里直接調(diào)用了，二是進(jìn)程自己調(diào)用，那就是通過系統(tǒng)調(diào)用來調(diào)用mmap了。生成的vma也有兩種類型，文件映射vma和匿名映射vma，哪種類型取決于mmap的參數(shù)。文件映射vma，在發(fā)生缺頁異常時(shí)，分配的物理內(nèi)存要用文件的內(nèi)容來初始化，其物理內(nèi)存也被叫做文件頁。匿名映射vma，在發(fā)生缺頁異常時(shí)，直接分配物理內(nèi)存并初始化為0，其物理內(nèi)存也被叫做匿名頁。

	一個(gè)進(jìn)程的text段、data段、堆區(qū)、棧區(qū)都是vma，這些vma都是內(nèi)核為進(jìn)程調(diào)用mmap生成的。進(jìn)程自己也可以調(diào)用mmap來分配虛擬內(nèi)存。堆區(qū)和棧區(qū)是比較特殊的vma，棧區(qū)的vma會(huì)隨著棧的增長而自動(dòng)增長，堆區(qū)的vma則需要進(jìn)程用系統(tǒng)調(diào)用brk或者sbrk來增長。不過我們?cè)诜峙涠褍?nèi)存的時(shí)候都不是直接使用的系統(tǒng)調(diào)用，而是使用libc給我們提供的malloc接口，有了malloc接口，我們分配釋放堆內(nèi)存就方便多了。Malloc接口的實(shí)現(xiàn)叫做malloc庫，目前比較流行的malloc庫有ptmalloc、jemalloc、scudo等。

	八、內(nèi)存統(tǒng)計(jì)

	暫略

	8.1 總體統(tǒng)計(jì)

	8.2 進(jìn)程統(tǒng)計(jì)

	九、總結(jié)回顧

	前面我們講了這么多的東西，現(xiàn)在再來總結(jié)回顧一下。首先我們?cè)僦匦驴匆幌翷inux的內(nèi)存管理體系圖，我們邊看這個(gè)圖邊進(jìn)行總結(jié)。

	

	首先要強(qiáng)調(diào)的一點(diǎn)是，這么多的東西，都是在內(nèi)核里進(jìn)行管理的，內(nèi)核是可以操作這一切的。但是對(duì)進(jìn)程來說這些基本都是透明的，進(jìn)程只能看到自己的虛擬內(nèi)存空間，只能在自己空間里分配虛擬內(nèi)存，其它的，進(jìn)程什么也看不見、管不著。

	目前絕大部分的操作系統(tǒng)采用的內(nèi)存管理模式都是以分頁內(nèi)存為基礎(chǔ)的虛擬內(nèi)存機(jī)制。虛擬內(nèi)存機(jī)制的中心是MMU和頁表，MMU是需要硬件提供的，頁表是需要軟件來操作的。虛擬內(nèi)存左邊連著物理內(nèi)存管理，右邊連著虛擬內(nèi)存空間，左邊和右邊有著復(fù)雜的關(guān)系。物理內(nèi)存管理中，首先是對(duì)物理內(nèi)存的三級(jí)區(qū)劃，然后是對(duì)物理內(nèi)存的三級(jí)分配體系，最后是物理內(nèi)存的回收。虛擬內(nèi)存空間中，首先可以分為內(nèi)核空間和用戶空間，兩者在很多方面都有著顯著的不同。內(nèi)核空間是內(nèi)核運(yùn)行的地方，只有一份，永久存在，有特權(quán)，而且其內(nèi)存映射是提前映射、線性映射，不會(huì)換頁。用戶空間是進(jìn)程運(yùn)行的地方，有N份，隨著進(jìn)程的誕生而創(chuàng)建、進(jìn)程的死亡而銷毀。用戶空間中虛擬內(nèi)存的分配和物理內(nèi)存的分配是分開的，進(jìn)程只能分配虛擬內(nèi)存，物理內(nèi)存的分配是在進(jìn)程運(yùn)行過程中動(dòng)態(tài)且透明地分配的。用戶空間的物理內(nèi)存可以分為文件頁和匿名頁，頁幀回收的主要邏輯就是圍繞文件頁和匿名頁展開的。

	

	編輯：黃飛