面試官:你談談對物理內存和虛擬內存的理解,一文完全搞懂

文章每週持續更新,原創不易,「三連」讓更多人看到是對我最大的確定。能夠微信搜索公衆號「 後端技術學堂 」第一時間閱讀(通常比博客早更新一到兩篇)

今天繼續來學習Linux內存管理,什麼?你更想學時間管理,我不配,抱個西瓜去微博學吧。html

img

言歸正傳,上一篇文章 別再說你不懂Linux內存管理了,10張圖給你安排的明明白白! 分析了 Linux 內存管理機制,若是已經忘了的同窗還能夠回頭看下,而且也強烈建議先閱讀那一篇再來看這一篇。限於篇幅,上一篇沒有深刻學習物理內存管理和虛擬內存分配,今天就來學習一下。linux

經過前面的學習咱們知道,程序可沒這麼好騙,任你內存管理把虛擬地址空間玩出花來,到最後仍是要給程序實實在在的物理內存,否則程序就要罷工了,因此物理內存這麼重要的資源必定要好好管理起來使用(物理內存,就是你實實在在的內存條),那麼內核是如何管理物理內存的呢?git

物理內存管理

Linux 系統中經過分段和分頁機制,把物理內存劃分 4K 大小的內存頁 Page(也稱做頁框Page Frame),物理內存的分配和回收都是基於內存頁進行,把物理內存分頁管理的好處大大的。程序員

假如系統請求小塊內存,能夠預先分配一頁給它,避免了反覆的申請和釋放小塊內存帶來頻繁的系統開銷。github

假如系統須要大塊內存,則能夠用多頁內存拼湊,而沒必要要求大塊連續內存。你看無論內存大小都能收放自如,分頁機制多麼完美的解決方案!面試

But,理想很豐滿,現實很骨感。若是就直接這樣把內存分頁使用,再也不加額外的管理仍是存在一些問題,下面咱們來看下,系統在屢次分配和釋放物理頁的時候會遇到哪些問題。算法

物理頁管理面臨問題

物理內存頁分配會出現外部碎片和內部碎片問題,所謂的「內部」和「外部」是針對「頁框內外」而言,一個頁框內的內存碎片是內部碎片,多個頁框間的碎片是外部碎片。編程

外部碎片

當須要分配大塊內存的時候,要用好幾頁組合起來纔夠,而系統分配物理內存頁的時候會盡可能分配連續的內存頁面,頻繁的分配與回收物理頁致使大量的小塊內存夾雜在已分配頁面中間,造成外部碎片,舉個例子:後端

外部碎片

內部碎片

物理內存是按頁來分配的,這樣當實際只須要很小內存的時候,也會分配至少是 4K 大小的頁面,而內核中有不少須要以字節爲單位分配內存的場景,這樣原本只想要幾個字節而已卻不得不分配一頁內存,除去用掉的字節剩下的就造成了內部碎片。 緩存

內部碎片

頁面管理算法

方法總比困難多,由於存在上面的這些問題,聰明的程序員靈機一動,引入了頁面管理算法來解決上述的碎片問題。

Buddy(夥伴)分配算法

Linux 內核引入了夥伴系統算法(Buddy system),什麼意思呢?就是把相同大小的頁框塊用鏈表串起來,頁框塊就像手拉手的好夥伴,也是這個算法名字的由來。

具體的,全部的空閒頁框分組爲11個塊鏈表,每一個塊鏈表分別包含大小爲1,2,4,8,16,32,64,128,256,512和1024個連續頁框的頁框塊。最大能夠申請1024個連續頁框,對應4MB大小的連續內存。

夥伴系統

由於任何正整數均可以由 2^n 的和組成,因此總能找到合適大小的內存塊分配出去,減小了外部碎片產生 。

分配實例

好比:我須要申請4個頁框,可是長度爲4個連續頁框塊鏈表沒有空閒的頁框塊,夥伴系統會從連續8個頁框塊的鏈表獲取一個,並將其拆分爲兩個連續4個頁框塊,取其中一個,另一個放入連續4個頁框塊的空閒鏈表中。釋放的時候會檢查,釋放的這幾個頁框先後的頁框是否空閒,可否組成下一級長度的塊。

命令查看
[lemon]]# cat /proc/buddyinfo 
Node 0, zone      DMA      1      0      0      0      2      1      1      0      1      1      3 
Node 0, zone    DMA32   3198   4108   4940   4773   4030   2184    891    180     67     32    330 
Node 0, zone   Normal  42438  37404  16035   4386    610    121     22      3      0      0      1

slab分配器

看到這裏你可能會想,有了夥伴系統這下總能夠管理好物理內存了吧?不,還不夠,不然就沒有slab分配器什麼事了。

那什麼是slab分配器呢?

通常來講,內核對象的生命週期是這樣的:分配內存-初始化-釋放內存,內核中有大量的小對象,好比文件描述結構對象、任務描述結構對象,若是按照夥伴系統按頁分配和釋放內存,對小對象頻繁的執行「分配內存-初始化-釋放內存」會很是消耗性能。

夥伴系統分配出去的內存仍是以頁框爲單位,而對於內核的不少場景都是分配小片內存,遠用不到一頁內存大小的空間。 slab 分配器,經過將內存按使用對象不一樣再劃分紅不一樣大小的空間,應用於內核對象的緩存。

夥伴系統和slab不是二選一的關係,slab 內存分配器是對夥伴分配算法的補充。

大白話說原理

對於每一個內核中的相同類型的對象,如:task_struct、file_struct 等須要重複使用的小型內核數據對象,都會有個 slab 緩存池,緩存住大量經常使用的「已經初始化」的對象,每當要申請這種類型的對象時,就從緩存池的slab 列表中分配一個出去;而當要釋放時,將其從新保存在該列表中,而不是直接返回給夥伴系統,從而避免內部碎片,同時也大大提升了內存分配性能。

主要優勢
  • slab 內存管理基於內核小對象,不用每次都分配一頁內存,充分利用內存空間,避免內部碎片。
  • slab 對內核中頻繁建立和釋放的小對象作緩存,重複利用一些相同的對象,減小內存分配次數。
數據結構

slab分配器

kmem_cache 是一個cache_chain 的鏈表組成節點,表明的是一個內核中的相同類型的「對象高速緩存」,每一個kmem_cache 一般是一段連續的內存塊,包含了三種類型的 slabs 鏈表:

  • slabs_full (徹底分配的 slab 鏈表)
  • slabs_partial (部分分配的slab 鏈表)
  • slabs_empty ( 沒有被分配對象的slab 鏈表)

kmem_cache 中有個重要的結構體 kmem_list3 包含了以上三個數據結構的聲明。

kmem_list3 內核源碼

slab slab 分配器的最小單位,在實現上一個 slab 有一個或多個連續的物理頁組成(一般只有一頁)。單個slab能夠在 slab 鏈表之間移動,例如若是一個「半滿 slabs_partial鏈表」被分配了對象後變滿了,就要從 slabs_partial 中刪除,同時插入到「全滿slabs_full鏈表」中去。內核 slab 對象的分配過程是這樣的:

  1. 若是 slabs_partial鏈表還有未分配的空間,分配對象,若分配以後變滿,移動 slabslabs_full 鏈表
  2. 若是 slabs_partial鏈表沒有未分配的空間,進入下一步
  3. 若是slabs_empty 鏈表還有未分配的空間,分配對象,同時移動 slab 進入 slabs_partial鏈表
  4. 若是slabs_empty爲空,請求夥伴系統分頁,建立一個新的空閒slab, 按步驟 3 分配對象

slab分配圖解

命令查看

上面說的都是理論,比較抽象,動動手來康康系統中的 slab 吧!你能夠經過 cat /proc/slabinfo 命令,實際查看系統中 slab 信息。

slabinfo查詢

slabtop 實時顯示內核 slab 內存緩存信息。

slabtop查詢

slab高速緩存的分類

slab高速緩存分爲兩大類,「通用高速緩存」和「專用高速緩存」。

通用高速緩存

slab分配器中用 kmem_cache 來描述高速緩存的結構,它自己也須要 slab 分配器對其進行高速緩存。cache_cache 保存着對「高速緩存描述符的高速緩存」,是一種通用高速緩存,保存在cache_chain 鏈表中的第一個元素。

另外,slab 分配器所提供的小塊連續內存的分配,也是通用高速緩存實現的。通用高速緩存所提供的對象具備幾何分佈的大小,範圍爲32到131072字節。內核中提供了 kmalloc()kfree() 兩個接口分別進行內存的申請和釋放。

專用高速緩存

內核爲專用高速緩存的申請和釋放提供了一套完整的接口,根據所傳入的參數爲制定的對象分配slab緩存。

專用高速緩存的申請和釋放

kmem_cache_create() 用於對一個指定的對象建立高速緩存。它從 cache_cache 普通高速緩存中爲新的專有緩存分配一個高速緩存描述符,並把這個描述符插入到高速緩存描述符造成的 cache_chain 鏈表中。kmem_cache_destory() 用於撤消和從 cache_chain 鏈表上刪除高速緩存。

slab的申請和釋放

slab 數據結構在內核中的定義,以下:

slab結構體內核代碼

kmem_cache_alloc() 在其參數所指定的高速緩存中分配一個slab,對應的 kmem_cache_free() 在其參數所指定的高速緩存中釋放一個slab。

虛擬內存分配

前面討論的都是對物理內存的管理,Linux 經過虛擬內存管理,欺騙了用戶程序僞裝每一個程序都有 4G 的虛擬內存尋址空間(若是這裏不懂我說啥,建議回頭看下 別再說你不懂Linux內存管理了,10張圖給你安排的明明白白!)。

因此咱們來研究下虛擬內存的分配,這裏包括用戶空間虛擬內存和內核空間虛擬內存。

注意,分配的虛擬內存尚未映射到物理內存,只有當訪問申請的虛擬內存時,纔會發生缺頁異常,再經過上面介紹的夥伴系統和 slab 分配器申請物理內存。

用戶空間內存分配

malloc

malloc 用於申請用戶空間的虛擬內存,當申請小於 128KB 小內存的時, malloc 使用 sbrk或brk 分配內存;當申請大於 128KB 的內存時,使用 mmap 函數申請內存;

存在問題

因爲 brk/sbrk/mmap 屬於系統調用,若是每次申請內存都要產生系統調用開銷,cpu 在用戶態和內核態之間頻繁切換,很是影響性能。

並且,堆是從低地址往高地址增加,若是低地址的內存沒有被釋放,高地址的內存就不能被回收,容易產生內存碎片。

解決

所以, malloc 採用的是內存池的實現方式,先申請一大塊內存,而後將內存分紅不一樣大小的內存塊,而後用戶申請內存時,直接從內存池中選擇一塊相近的內存塊分配出去。
malloc原理

內核空間內存分配

在講內核空間內存分配以前,先來回顧一下內核地址空間。kmallocvmalloc 分別用於分配不一樣映射區的虛擬內存。

內核空間細分區域.

kmalloc

kmalloc() 分配的虛擬地址範圍在內核空間的「直接內存映射區」。

按字節爲單位虛擬內存,通常用於分配小塊內存,釋放內存對應於 kfree ,能夠分配連續的物理內存。函數原型在 <linux/kmalloc.h> 中聲明,通常狀況下在驅動程序中都是調用 kmalloc() 來給數據結構分配內存 。

還記得前面說的 slab 嗎?kmalloc 是基於slab 分配器的 ,一樣能夠用cat /proc/slabinfo 命令,查看 kmalloc 相關 slab 對象信息,下面的 kmalloc-八、kmalloc-16 等等就是基於slab分配的 kmalloc 高速緩存。

slabinfo-kmalloc

vmalloc

vmalloc 分配的虛擬地址區間,位於 vmalloc_start vmalloc_end 之間的「動態內存映射區」。

通常用分配大塊內存,釋放內存對應於 vfree,分配的虛擬內存地址連續,物理地址上不必定連續。函數原型在 <linux/vmalloc.h> 中聲明。通常用在爲活動的交換區分配數據結構,爲某些 I/O 驅動程序分配緩衝區,或爲內核模塊分配空間。

下面的圖總結了上述兩種內核空間虛擬內存分配方式。
kmalloc_vmalloc圖解

總結一下

這是Linux 內存管理系列文章的下篇,強烈建議閱讀過程當中有不清楚的同窗,先去看看我以前寫的 別再說你不懂Linux內存管理了,10張圖給你安排的明明白白!,寫到這裏Linux 內存管理專題告一段落,我分享的這些知識很基礎,基礎到平常開發工做幾乎用不上,但我認爲每一個在Linux下開發人員都應該瞭解。

我知道有些面試官喜歡在面試的時候考察一下,或多或少反應候選人基礎素養,這兩篇文章的內容也足夠應付面試。仍是那句話,Linxu 內存管理太複雜,不是一兩篇文章能講的清楚,但至少要有宏觀意識,不至於一問三不知,若是你想深刻了解原理,強烈建議從書中並結合內核源碼學習,天天進步一點點,咱們的目標是星辰大海。

本文創做過程我也畫了大量的示例圖解,能夠做爲知識索引,我的感受看圖仍是比看文字更清晰明瞭,你能夠在我公衆號「後端技術學堂」後臺回覆「內存管理」獲取這些圖片的高清原圖。

老規矩,感謝各位的閱讀,文章的目的是分享對知識的理解,技術類文章我都會反覆求證以求最大程度保證準確性,若文中出現明顯紕漏也歡迎指出,咱們一塊兒在探討中學習。今天的技術分享就到這裏,咱們下期再見。

Reference

《Linux內核設計與實現(原書第3版)》

linux內核slab機制分析 https://www.jianshu.com/p/95d...

Linux內存管理中的slab分配器 http://edsionte.com/techblog/...

Linux slab 分配器剖析 https://www.ibm.com/developer...

Linux內核內存管理算法Buddy和Slab https://zhuanlan.zhihu.com/p/...

Linux內存之Slab https://fivezh.github.io/2017...

malloc 的實現原理 內存池 mmap sbrk 鏈表 https://zhuanlan.zhihu.com/p/...

malloc實現原理 http://luodw.cc/2016/02/17/ma...

glibc內存管理那些事兒 https://www.jianshu.com/p/2fe...

原創不易,看到這裏動動手指,各位的「 轉發和點贊」是對我持續創做的最大支持,咱們下篇文章再見。

能夠微信搜索公衆號「 後端技術學堂 」回覆「資料」「1024」有我給你準備的各類編程學習資料。文章每週持續更新,咱們下期見!
相關文章
相關標籤/搜索