华南俳烁实业有限公司

現(xiàn)在的服務器大部分都是運行在Linux上面的，所以，作為一個程序員有必要簡單地了解一下系統(tǒng)是如何運行的。對于內(nèi)存部分需要知道：

1. 地址映射
2. 內(nèi)存管理的方式
3. 缺頁異常

先來看一些基本的知識，在進程看來，內(nèi)存分為內(nèi)核態(tài)和用戶態(tài)兩部分，經(jīng)典比例如下：

從用戶態(tài)到內(nèi)核態(tài)一般通過系統(tǒng)調(diào)用、中斷來實現(xiàn)。用戶態(tài)的內(nèi)存被劃分為不同的區(qū)域用于不同的目的：

當然內(nèi)核態(tài)也不會無差別地使用，所以，其劃分如下：

下面來仔細看這些內(nèi)存是如何管理的。

地址

在Linux內(nèi)部的地址的映射過程為邏輯地址–>線性地址–>物理地址，物理地址最簡單：地址總線中傳輸?shù)臄?shù)字信號，而線性地址和邏輯地址所表示的則是一種轉(zhuǎn)換規(guī)則，線性地址規(guī)則如下：

這部分由MMU完成，其中涉及到主要的寄存器有CR0、CR3。機器指令中出現(xiàn)的是邏輯地址，邏輯地址規(guī)則如下：

在Linux中的邏輯地址等于線性地址，也就是說Inter為了兼容把事情搞得很復雜，Linux簡化順便偷個懶。

內(nèi)存管理的方式

在系統(tǒng)boot的時候會去探測內(nèi)存的大小和情況，在建立復雜的結構之前，需要用一個簡單的方式來管理這些內(nèi)存，這就是bootmem，簡單來說就是位圖，不過其中也有一些優(yōu)化的思路。

bootmem再怎么優(yōu)化，效率都不高，在要分配內(nèi)存的時候畢竟是要去遍歷，buddy系統(tǒng)剛好能解決這個問題：在內(nèi)部保存一些2的冪次大小的空閑內(nèi)存片段，如果要分配3page，去4page的列表里面取一個，分配3個之后將剩下的1個放回去，內(nèi)存釋放的過程剛好是一個逆過程。用一個圖來表示：

可以看到0、4、5、6、7都是正在使用的，那么，1、2被釋放的時候，他們會合并嗎？

staticinlineunsignedlong
__find_buddy_index(unsignedlong page_idx,unsignedint order){return page_idx ^(1<< order);// 更新最高位，0～1互換}

從上面這段代碼中可以看到，0、1是buddy，2、3是buddy，雖然1、2相鄰，但他們不是。內(nèi)存碎片是系統(tǒng)運行的大敵，伙伴系統(tǒng)機制可以在一定程度上防止碎片~~另外，我們可以通過cat /proc/buddyinfo獲取到各order中的空閑的頁面數(shù)。

伙伴系統(tǒng)每次分配內(nèi)存都是以頁（4KB）為單位的，但系統(tǒng)運行的時候使用的絕大部分的數(shù)據(jù)結構都是很小的，為一個小對象分配4KB顯然是不劃算了。Linux中使用slab來解決小對象的分配：

在運行時，slab向buddy“批發(fā)”一些內(nèi)存，加工切塊以后“散賣”出去。隨著大規(guī)模多處理器系統(tǒng)和NUMA系統(tǒng)的廣泛應用，slab終于暴露出不足：

1. 復雜的隊列管理
2. 管理數(shù)據(jù)和隊列存儲開銷較大
3. 長時間運行partial隊列可能會非常長
4. 對NUMA支持非常復雜

為了解決這些高手們開發(fā)了slub：改造page結構來削減slab管理結構的開銷、每個CPU都有一個本地活動的slab(kmem_cache_cpu)等。對于小型的嵌入式系統(tǒng)存在一個slab模擬層slob，在這種系統(tǒng)中它更有優(yōu)勢。

小內(nèi)存的問題算是解決了，但還有一個大內(nèi)存的問題：用伙伴系統(tǒng)分配10 x 4KB的數(shù)據(jù)時，會去16 x 4KB的空閑列表里面去找（這樣得到的物理內(nèi)存是連續(xù)的），但很有可能系統(tǒng)里面有內(nèi)存，但是伙伴系統(tǒng)分配不出來，因為他們被分割成小的片段。那么，vmalloc就是要用這些碎片來拼湊出一個大內(nèi)存，相當于收集一些“邊角料”，組裝成一個成品后“出售”：

之前的內(nèi)存都是直接映射的，第一次感覺到頁式管理的存在:D 另外對于高端內(nèi)存，提供了kmap方法為page分配一個線性地址。