針對Linux記憶體管理知識學習總結

現在的伺服器大部分都是執行在linux上面的，所以，作為乙個程式設計師有必要簡單地了解一下系統是如何執行的。對於記憶體部分需要知道：

先來看一些基本的知識，在程序看來，記憶體分為核心態和使用者態兩部分，經典比例如下：

從使用者態到核心態一般通過系統呼叫、中斷來實現。使用者態的記憶體被劃分為不同的區域用於不同的目的：

當然核心態也不會無差別地使用，所以，其劃分如下：

下面來仔細看這些記憶體是如何管理的。

位址

在linux內部的位址的對映過程為邏輯位址–>線性位址–>實體地址，實體地址最簡單：位址匯流排中傳輸的數碼訊號，而線性位址和邏輯位址所表示的則是一種轉換規則，線性位址規則如下：

在linux中的邏輯位址等於線性位址，也就是說inter為了相容把事情搞得很複雜，linux簡化順便偷個懶。

記憶體管理的方式

在系統boot的時候會去探測記憶體的大小和情況，在建立複雜的結構之前，需要用乙個簡單的方式來管理這些記憶體，這就是bootmem，簡單來說就是位圖，不過其中也有一些優化的思路。

bootmem再怎麼優化，效率都不高，在要分配記憶體的時候畢竟是要去遍歷，buddy系統剛好能解決這個問題：在內部儲存一些2的冪次大小的空閒記憶體片段，如果要分配3page，去4page的列表裡面取乙個，分配3個之後將剩下的1個放回去，記憶體釋放的過程剛好是乙個逆過程。用乙個圖來表示：

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

static inline unsigned long

__find_buddy_index(unsigned long page_idx, unsigned int order)

從上面這段**中可以看到，0、1是buddy，2、3是buddy，雖然1、2相鄰，但他們不是。記憶體碎片是系統執行的大敵，夥伴系統機制可以在一定程度上防止碎片~~另外，我們可以通過cat /proc/buddyinfo獲取到各order中的空閒的頁面數。

夥伴系統每次分配記憶體都是以頁（4kb）為單位的，但系統執行的時候使用的絕大部分的資料結構都是很小的，為乙個小物件分配4kb顯然是不划算了。linux中使用slab來解決小物件的分配：

在執行時，slab向buddy「批發」一些記憶體，加工切塊以後「散賣」出去。隨著大規模多處理器系統和numa系統的廣泛應用，slab終於暴露出不足：

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

小記憶體的問題算是解決了，但還有乙個大記憶體的問題：用夥伴系統分配10 x 4kb的資料時，會去16 x 4kb的空閒列表裡面去找（這樣得到的物理記憶體是連續的），但很有可能系統裡面有記憶體，但是夥伴系統分配不出來，因為他們被分割成小的片段。那麼，vmalloc就是要用這些碎片來拼湊出乙個大記憶體，相當於收集一些「邊角料」，組裝成乙個成品後「**」：

之前的記憶體都是直接對映的，第一次感覺到頁式管理的存在:d 另外對於高階記憶體，提供了kmap方法為page分配乙個線性位址。

在我們寫**malloc完以後，並沒有馬上占用那麼大的物理記憶體，而僅僅是維護上面的虛擬位址空間而已，只有在真正需要的時候才分配物理記憶體，這就是cow（copy-on-write:寫時複製）技術，而物理分配的過程就是最複雜的缺頁異常處理環節了，下面來看!

缺頁異常

在實際需要某個虛擬記憶體區域的資料之前，和物理記憶體之間的對映關係不會建立。如果程序訪問的虛擬位址空間部分尚未與頁幀關聯，處理器自動引發乙個缺頁異常。在核心處理缺頁異常時可以拿到的資訊如下：

err_code：異常發生時由控制單元壓入棧中，表示發生異常的原因

regs：發生異常時暫存器的值

處理的流程如下：

命令作用swapon

開啟swap

swapoff

關閉swap

如果記憶體是mmap對映到記憶體中的，那麼在讀、寫對應記憶體的時候也會產生缺頁異常。

針對Linux記憶體管理知識學習總結

記憶體管理知識

記憶體管理知識

Mac OS 記憶體管理知識

相關推薦