Linux記憶體管理（最透徹的一篇）【轉】

• 2019 年 10 月 10 日
• 筆記

轉自：https://www.cnblogs.com/ralap7/p/9184773.html

摘要：本章首先以應用程式開發者的角度審視Linux的進程記憶體管理，在此基礎上逐步深入到內核中討論系統物理記憶體管理和內核記憶體的使用方法。力求從外到內、水到渠成地引導網友分析Linux的記憶體管理與使用。在本章最後，我們給出一個記憶體映射的實例，幫助網友們理解內核記憶體管理與用戶記憶體管理之間的關係，希望大家最終能駕馭Linux記憶體管理。

前言

記憶體管理一向是所有作業系統書籍不惜筆墨重點討論的內容，無論市面上或是網上都充斥著大量涉及記憶體管理的教材和資料。因此，我們這裡所要寫的Linux記憶體管理採取避重就輕的策略，從理論層面就不去班門弄斧，貽笑大方了。我們最想做的和可能做到的是從開發者的角度談談對記憶體管理的理解，最終目的是把我們在內核開發中使用記憶體的經驗和對Linux記憶體管理的認識與大家共享。

當然，這其中我們也會涉及到一些諸如段頁等記憶體管理的基本理論，但我們的目的不是為了強調理論，而是為了指導理解開發中的實踐，所以僅僅點到為止，不做深究。

遵循「理論來源於實踐」的「教條」，我們先不必一下子就鑽入內核里去看系統記憶體到底是如何管理，那樣往往會讓你陷入似懂非懂的窘境（我當年就犯了這個錯誤！）。所以最好的方式是先從外部（用戶編程範疇）來觀察進程如何使用記憶體，等到大家對記憶體的使用有了較直觀的認識後，再深入到內核中去學習記憶體如何被管理等理論知識。最後再通過一個實例編程將所講內容融會貫通。

進程與記憶體

進程如何使用記憶體？

毫無疑問，所有進程（執行的程式）都必須佔用一定數量的記憶體，它或是用來存放從磁碟載入的程式程式碼，或是存放取自用戶輸入的數據等等。不過進程對這些記憶體的管理方式因記憶體用途不一而不盡相同，有些記憶體是事先靜態分配和統一回收的，而有些卻是按需要動態分配和回收的。

對任何一個普通進程來講，它都會涉及到5種不同的數據段。稍有編程知識的朋友都能想到這幾個數據段中包含有「程式程式碼段」、「程式數據段」、「程式堆棧段」等。不錯，這幾種數據段都在其中，但除了以上幾種數據段之外，進程還另外包含兩種數據段。下面我們來簡單歸納一下進程對應的記憶體空間中所包含的5種不同的數據區。

程式碼段：程式碼段是用來存放可執行文件的操作指令，也就是說是它是可執行程式在記憶體中的鏡像。程式碼段需要防止在運行時被非法修改，所以只准許讀取操作，而不允許寫入（修改）操作——它是不可寫的。

數據段：數據段用來存放可執行文件中已初始化全局變數，換句話說就是存放程式靜態分配[1]的變數和全局變數。

BSS段[2]：BSS段包含了程式中未初始化的全局變數，在記憶體中 bss段全部置零。

堆（heap）：堆是用於存放進程運行中被動態分配的記憶體段，它的大小並不固定，可動態擴張或縮減。當進程調用malloc等函數分配記憶體時，新分配的記憶體就被動態添加到堆上（堆被擴張）；當利用free等函數釋放記憶體時，被釋放的記憶體從堆中被剔除（堆被縮減）

棧：棧是用戶存放程式臨時創建的局部變數，也就是說我們函數括弧「{}」中定義的變數（但不包括static聲明的變數，static意味著在數據段中存放變數）。除此以外，在函數被調用時，其參數也會被壓入發起調用的進程棧中，並且待到調用結束後，函數的返回值也會被存放回棧中。由於棧的先進先出特點，所以棧特別方便用來保存/恢復調用現場。從這個意義上講，我們可以把堆棧看成一個寄存、交換臨時數據的記憶體區。

進程如何組織這些區域？

上述幾種記憶體區域中數據段、BSS和堆通常是被連續存儲的——記憶體位置上是連續的，而程式碼段和棧往往會被獨立存放。有趣的是，堆和棧兩個區域關係很「曖昧」，他們一個向下「長」（i386體系結構中棧向下、堆向上），一個向上「長」，相對而生。但你不必擔心他們會碰頭，因為他們之間間隔很大（到底大到多少，你可以從下面的例子程式計算一下），絕少有機會能碰到一起。

下圖簡要描述了進程記憶體區域的分布：

「事實勝於雄辯」，我們用一個小例子（原形取自《User-Level Memory Management》）來展示上面所講的各種記憶體區的差別與位置。

#include<stdio.h>    #include<malloc.h>    #include<unistd.h>    int bss_var;    int data_var0=1;    int main(int argc,char **argv)    {      　　printf("below are addresses of types of process's memn");      　　printf("Text location:n");      　　printf("tAddress of main(Code Segment):%pn",main);      　　printf("____________________________n");      　　int stack_var0=2;      　　printf("Stack Location:n");      　　printf("tInitial end of stack:%pn",&stack_var0);      　　int stack_var1=3;      　　printf("tnew end of stack:%pn",&stack_var1);      　　printf("____________________________n");      　　printf("Data Location:n");      　　printf("tAddress of data_var(Data Segment):%pn",&data_var0);      　　static int data_var1=4;      　　printf("tNew end of data_var(Data Segment):%pn",&data_var1);     　　 printf("____________________________n");      　　printf("BSS Location:n");      　　printf("tAddress of bss_var:%pn",&bss_var);     　　 printf("____________________________n");      　　char *b = sbrk((ptrdiff_t)0);     　　 printf("Heap Location:n");     　　 printf("tInitial end of heap:%pn",b);     　　 brk(b+4);      　　b=sbrk((ptrdiff_t)0);      　　printf("tNew end of heap:%pn",b);    　　  return 0;     }

它的結果如下：

below are addresses of types of process's mem    Text location:       Address of main(Code Segment):0x8048388    ____________________________    Stack Location:       Initial end of stack:0xbffffab4       new end of stack:0xbffffab0    ____________________________    Data Location:       Address of data_var(Data Segment):0x8049758       New end of data_var(Data Segment):0x804975c    ____________________________    BSS Location:       Address of bss_var:0x8049864    ____________________________    Heap Location:       Initial end of heap:0x8049868       New end of heap:0x804986c

利用size命令也可以看到程式的各段大小，比如執行size example會得到

　　text data bss dec hex filename

　　1654 280 8 1942 796 example

但這些數據是程式編譯的靜態統計，而上面顯示的是進程運行時的動態值，但兩者是對應的。

通過前面的例子，我們對進程使用的邏輯記憶體分布已先睹為快。這部分我們就繼續進入作業系統內核看看，進程對記憶體具體是如何進行分配和管理的。

從用戶向內核看，所使用的記憶體表象形式會依次經歷「邏輯地址」——「線性地址」——「物理地址」幾種形式（關於幾種地址的解釋在前面已經講述了）。邏輯地址經段機制轉化成線性地址；線性地址又經過頁機制轉化為物理地址。（但是我們要知道Linux系統雖然保留了段機制，但是將所有程式的段地址都定死為0-4G，所以雖然邏輯地址和線性地址是兩種不同的地址空間，但在Linux中邏輯地址就等於線性地址，它們的值是一樣的）。沿著這條線索，我們所研究的主要問題也就集中在下面幾個問題。

1. 進程空間地址如何管理？

2. 進程地址如何映射到物理記憶體？

3. 物理記憶體如何被管理？

以及由上述問題引發的一些子問題。如系統虛擬地址分布；記憶體分配介面；連續記憶體分配與非連續記憶體分配等。

進程記憶體空間

Linux作業系統採用虛擬記憶體管理技術，使得每個進程都有各自互不干涉的進程地址空間。該空間是塊大小為4G的線性虛擬空間，用戶所看到和接觸到的都是該虛擬地址，無法看到實際的物理記憶體地址。利用這種虛擬地址不但能起到保護作業系統的效果（用戶不能直接訪問物理記憶體），而且更重要的是，用戶程式可使用比實際物理記憶體更大的地址空間（具體的原因請看硬體基礎部分）。

在討論進程空間細節前，這裡先要澄清下面幾個問題：

l 第一、4G的進程地址空間被人為的分為兩個部分——用戶空間與內核空間。用戶空間從0到3G（0xC0000000），內核空間佔據3G到4G。用戶進程通常情況下只能訪問用戶空間的虛擬地址，不能訪問內核空間虛擬地址。只有用戶進程進行系統調用（代表用戶進程在內核態執行）等時刻可以訪問到內核空間。

l 第二、用戶空間對應進程，所以每當進程切換，用戶空間就會跟著變化；而內核空間是由內核負責映射，它並不會跟著進程改變，是固定的。內核空間地址有自己對應的頁表（init_mm.pgd），用戶進程各自有不同的頁表。

l 第三、每個進程的用戶空間都是完全獨立、互不相干的。不信的話，你可以把上面的程式同時運行10次（當然為了同時運行，讓它們在返回前一同睡眠100秒吧），你會看到10個進程佔用的線性地址一模一樣。

進程記憶體管理

進程記憶體管理的對象是進程線性地址空間上的記憶體鏡像，這些記憶體鏡像其實就是進程使用的虛擬記憶體區域（memory region）。進程虛擬空間是個32或64位的「平坦」（獨立的連續區間）地址空間（空間的具體大小取決於體系結構）。要統一管理這麼大的平坦空間可絕非易事，為了方便管理，虛擬空間被劃分為許多大小可變的(但必須是4096的倍數)記憶體區域，這些區域在進程線性地址中像停車位一樣有序排列。這些區域的劃分原則是「將訪問屬性一致的地址空間存放在一起」，所謂訪問屬性在這裡無非指的是「可讀、可寫、可執行等」。

如果你要查看某個進程佔用的記憶體區域，可以使用命令cat /proc/<pid>/maps獲得（pid是進程號，你可以運行上面我們給出的例子——./example &;pid便會列印到螢幕），你可以發現很多類似於下面的數字資訊。

由於程式example使用了動態庫，所以除了example本身使用的的記憶體區域外，還會包含那些動態庫使用的記憶體區域（區域順序是：程式碼段、數據段、bss段）。

我們下面只抽出和example有關的資訊，除了前兩行代表的程式碼段和數據段外，最後一行是進程使用的棧空間。

——————————————————————————-

08048000 – 08049000 r-xp 00000000 03:03 439029 /home/mm/src/example

08049000 – 0804a000 rw-p 00000000 03:03 439029 /home/mm/src/example

……………

bfffe000 – c0000000 rwxp ffff000 00:00 0

———————————————————————————————————————-

每行數據格式如下：

（記憶體區域）開始－結束 訪問許可權 偏移 主設備號：次設備號 i節點 文件。

注意，你一定會發現進程空間只包含三個記憶體區域，似乎沒有上面所提到的堆、bss等，其實並非如此，程式記憶體段和進程地址空間中的記憶體區域是種模糊對應，也就是說，堆、bss、數據段（初始化過的）都在進程空間中由數據段記憶體區域表示。

在Linux內核中對應進程記憶體區域的數據結構是: vm_area_struct, 內核將每個記憶體區域作為一個單獨的記憶體對象管理，相應的操作也都一致。採用面向對象方法使VMA結構體可以代表多種類型的記憶體區域－－比如記憶體映射文件或進程的用戶空間棧等，對這些區域的操作也都不盡相同。

vm_area_strcut結構比較複雜，關於它的詳細結構請參閱相關資料。我們這裡只對它的組織方法做一點補充說明。vm_area_struct是描述進程地址空間的基本管理單元，對於一個進程來說往往需要多個記憶體區域來描述它的虛擬空間，如何關聯這些不同的記憶體區域呢？大家可能都會想到使用鏈表，的確vm_area_struct結構確實是以鏈表形式鏈接，不過為了方便查找，內核又以紅黑樹（以前的內核使用平衡樹）的形式組織記憶體區域，以便降低搜索耗時。並存的兩種組織形式，並非冗餘：鏈表用於需要遍歷全部節點的時候用，而紅黑樹適用於在地址空間中定位特定記憶體區域的時候。內核為了記憶體區域上的各種不同操作都能獲得高性能，所以同時使用了這兩種數據結構。

下圖反映了進程地址空間的管理模型：

進程的地址空間對應的描述結構是「記憶體描述符結構」,它表示進程的全部地址空間，——包含了和進程地址空間有關的全部資訊，其中當然包含進程的記憶體區域。

進程記憶體的分配與回收

創建進程fork()、程式載入execve()、映射文件mmap()、動態記憶體分配malloc()/brk()等進程相關操作都需要分配記憶體給進程。不過這時進程申請和獲得的還不是實際記憶體，而是虛擬記憶體，準確的說是「記憶體區域」。進程對記憶體區域的分配最終都會歸結到do_mmap（）函數上來（brk調用被單獨以系統調用實現，不用do_mmap()），

內核使用do_mmap()函數創建一個新的線性地址區間。但是說該函數創建了一個新VMA並不非常準確，因為如果創建的地址區間和一個已經存在的地址區間相鄰，並且它們具有相同的訪問許可權的話，那麼兩個區間將合併為一個。如果不能合併，那麼就確實需要創建一個新的VMA了。但無論哪種情況， do_mmap()函數都會將一個地址區間加入到進程的地址空間中－－無論是擴展已存在的記憶體區域還是創建一個新的區域。

同樣，釋放一個記憶體區域應使用函數do_ummap()，它會銷毀對應的記憶體區域。

如何由虛變實！

從上面已經看到進程所能直接操作的地址都為虛擬地址。當進程需要記憶體時，從內核獲得的僅僅是虛擬的記憶體區域，而不是實際的物理地址，進程並沒有獲得物理記憶體（物理頁面——頁的概念請大家參考硬體基礎一章），獲得的僅僅是對一個新的線性地址區間的使用權。實際的物理記憶體只有當進程真的去訪問新獲取的虛擬地址時，才會由「請求頁機制」產生「缺頁」異常，從而進入分配實際頁面的常式。

該異常是虛擬記憶體機制賴以存在的基本保證——它會告訴內核去真正為進程分配物理頁，並建立對應的頁表，這之後虛擬地址才實實在在地映射到了系統的物理記憶體上。（當然，如果頁被換出到磁碟，也會產生缺頁異常，不過這時不用再建立頁表了）

這種請求頁機制把頁面的分配推遲到不能再推遲為止，並不急於把所有的事情都一次做完（這種思想有點像設計模式中的代理模式（proxy））。之所以能這麼做是利用了記憶體訪問的「局部性原理」，請求頁帶來的好處是節約了空閑記憶體，提高了系統的吞吐率。要想更清楚地了解請求頁機制，可以看看《深入理解linux內核》一書。

這裡我們需要說明在記憶體區域結構上的nopage操作。當訪問的進程虛擬記憶體並未真正分配頁面時，該操作便被調用來分配實際的物理頁，並為該頁建立頁表項。在最後的例子中我們會演示如何使用該方法。

系統物理記憶體管理

雖然應用程式操作的對象是映射到物理記憶體之上的虛擬記憶體，但是處理器直接操作的卻是物理記憶體。所以當應用程式訪問一個虛擬地址時，首先必須將虛擬地址轉化成物理地址，然後處理器才能解析地址訪問請求。地址的轉換工作需要通過查詢頁表才能完成，概括地講，地址轉換需要將虛擬地址分段，使每段虛地址都作為一個索引指向頁表，而頁表項則指向下一級別的頁表或者指向最終的物理頁面。

每個進程都有自己的頁表。進程描述符的pgd域指向的就是進程的頁全局目錄。下面我們借用《linux設備驅動程式》中的一幅圖大致看看進程地址空間到物理頁之間的轉換關係。

上面的過程說起來簡單，做起來難呀。因為在虛擬地址映射到頁之前必須先分配物理頁——也就是說必須先從內核中獲取空閑頁，並建立頁表。下面我們介紹一下內核管理物理記憶體的機制。

物理記憶體管理（頁管理）

Linux內核管理物理記憶體是通過分頁機制實現的，它將整個記憶體劃分成無數個4k（在i386體系結構中）大小的頁，從而分配和回收記憶體的基本單位便是記憶體頁了。利用分頁管理有助於靈活分配記憶體地址，因為分配時不必要求必須有大塊的連續記憶體[3]，系統可以東一頁、西一頁的湊出所需要的記憶體供進程使用。雖然如此，但是實際上系統使用記憶體時還是傾向於分配連續的記憶體塊，因為分配連續記憶體時，頁表不需要更改，因此能降低TLB的刷新率（頻繁刷新會在很大程度上降低訪問速度）。

鑒於上述需求，內核分配物理頁面時為了盡量減少不連續情況，採用了「夥伴」關係來管理空閑頁面。夥伴關係分配演算法大家應該不陌生——幾乎所有作業系統方面的書都會提到,我們不去詳細說它了，如果不明白可以參看有關資料。這裡只需要大家明白Linux中空閑頁面的組織和管理利用了夥伴關係，因此空閑頁面分配時也需要遵循夥伴關係，最小單位只能是2的冪倍頁面大小。內核中分配空閑頁面的基本函數是get_free_page/get_free_pages，它們或是分配單頁或是分配指定的頁面（2、4、8…512頁）。

注意：get_free_page是在內核中分配記憶體，不同於malloc在用戶空間中分配，malloc利用堆動態分配，實際上是調用brk()系統調用，該調用的作用是擴大或縮小進程堆空間（它會修改進程的brk域）。如果現有的記憶體區域不夠容納堆空間，則會以頁面大小的倍數為單位，擴張或收縮對應的記憶體區域，但brk值並非以頁面大小為倍數修改，而是按實際請求修改。因此Malloc在用戶空間分配記憶體可以以位元組為單位分配,但內核在內部仍然會是以頁為單位分配的。

另外,需要提及的是，物理頁在系統中由頁結構struct page描述，系統中所有的頁面都存儲在數組mem_map[]中，可以通過該數組找到系統中的每一頁（空閑或非空閑）。而其中的空閑頁面則可由上述提到的以夥伴關係組織的空閑頁鏈表（free_area[MAX_ORDER]）來索引。

內核記憶體使用

Slab

所謂尺有所長，寸有所短。以頁為最小單位分配記憶體對於內核管理系統中的物理記憶體來說的確比較方便，但內核自身最常使用的記憶體卻往往是很小（遠遠小於一頁）的記憶體塊——比如存放文件描述符、進程描述符、虛擬記憶體區域描述符等行為所需的記憶體都不足一頁。這些用來存放描述符的記憶體相比頁面而言，就好比是麵包屑與麵包。一個整頁中可以聚集多個這些小塊記憶體；而且這些小塊記憶體塊也和麵包屑一樣頻繁地生成/銷毀。

為了滿足內核對這種小記憶體塊的需要，Linux系統採用了一種被稱為slab分配器的技術。Slab分配器的實現相當複雜，但原理不難，其核心思想就是「存儲池[4]」的運用。記憶體片段（小塊記憶體）被看作對象，當被使用完後，並不直接釋放而是被快取到「存儲池」里，留做下次使用，這無疑避免了頻繁創建與銷毀對象所帶來的額外負載。

Slab技術不但避免了記憶體內部分片（下文將解釋）帶來的不便（引入Slab分配器的主要目的是為了減少對夥伴系統分配演算法的調用次數——頻繁分配和回收必然會導致記憶體碎片——難以找到大塊連續的可用記憶體），而且可以很好地利用硬體快取提高訪問速度。

Slab並非是脫離夥伴關係而獨立存在的一種記憶體分配方式，slab仍然是建立在頁面基礎之上，換句話說，Slab將頁面（來自於夥伴關係管理的空閑頁面鏈表）撕碎成眾多小記憶體塊以供分配，slab中的對象分配和銷毀使用kmem_cache_alloc與kmem_cache_free。

Kmalloc

Slab分配器不僅僅只用來存放內核專用的結構體，它還被用來處理內核對小塊記憶體的請求。當然鑒於Slab分配器的特點，一般來說內核程式中對小於一頁的小塊記憶體的請求才通過Slab分配器提供的介面Kmalloc來完成（雖然它可分配32 到131072位元組的記憶體）。從內核記憶體分配的角度來講，kmalloc可被看成是get_free_page（s）的一個有效補充，記憶體分配粒度更靈活了。

有興趣的話，可以到/proc/slabinfo中找到內核執行現場使用的各種slab資訊統計，其中你會看到系統中所有slab的使用資訊。從資訊中可以看到系統中除了專用結構體使用的slab外，還存在大量為Kmalloc而準備的Slab（其中有些為dma準備的）。

內核非連續記憶體分配（Vmalloc）

夥伴關係也好、slab技術也好，從記憶體管理理論角度而言目的基本是一致的，它們都是為了防止「分片」，不過分片又分為外部分片和內部分片之說，所謂內部分片是說系統為了滿足一小段記憶體區（連續）的需要，不得不分配了一大區域連續記憶體給它，從而造成了空間浪費；外部分片是指系統雖有足夠的記憶體，但卻是分散的碎片，無法滿足對大塊「連續記憶體」的需求。無論何種分片都是系統有效利用記憶體的障礙。slab分配器使得一個頁面內包含的眾多小塊記憶體可獨立被分配使用，避免了內部分片，節約了空閑記憶體。夥伴關係把記憶體塊按大小分組管理，一定程度上減輕了外部分片的危害，因為頁框分配不在盲目，而是按照大小依次有序進行，不過夥伴關係只是減輕了外部分片，但並未徹底消除。你自己比劃一下多次分配頁面後，空閑記憶體的剩餘情況吧。

所以避免外部分片的最終思路還是落到了如何利用不連續的記憶體塊組合成「看起來很大的記憶體塊」——這裡的情況很類似於用戶空間分配虛擬記憶體，記憶體邏輯上連續，其實映射到並不一定連續的物理記憶體上。Linux內核借用了這個技術，允許內核程式在內核地址空間中分配虛擬地址，同樣也利用頁表（內核頁表）將虛擬地址映射到分散的記憶體頁上。以此完美地解決了內核記憶體使用中的外部分片問題。內核提供vmalloc函數分配內核虛擬記憶體，該函數不同於kmalloc，它可以分配較Kmalloc大得多的記憶體空間（可遠大於128K，但必須是頁大小的倍數），但相比Kmalloc來說,Vmalloc需要對內核虛擬地址進行重映射，必須更新內核頁表，因此分配效率上要低一些（用空間換時間）

與用戶進程相似,內核也有一個名為init_mm的mm_strcut結構來描述內核地址空間，其中頁表項pdg=swapper_pg_dir包含了系統內核空間（3G-4G）的映射關係。因此vmalloc分配內核虛擬地址必須更新內核頁表，而kmalloc或get_free_page由於分配的連續記憶體，所以不需要更新內核頁表。

vmalloc分配的內核虛擬記憶體與kmalloc/get_free_page分配的內核虛擬記憶體位於不同的區間，不會重疊。因為內核虛擬空間被分區管理，各司其職。進程空間地址分布從０到３G(其實是到PAGE_OFFSET,在0x86中它等於0xC0000000)，從3G到vmalloc_start這段地址是物理記憶體映射區域（該區域中包含了內核鏡像、物理頁面表mem_map等等）比如我使用的系統記憶體是64M(可以用free看到)，那麼(3G——3G+64M)這片記憶體就應該映射到物理記憶體，而vmalloc_start位置應在3G+64M附近（說"附近"因為是在物理記憶體映射區與vmalloc_start期間還會存在一個8M大小的gap來防止躍界）,vmalloc_end的位置接近4G(說"接近"是因為最後位置系統會保留一片128k大小的區域用於專用頁面映射，還有可能會有高端記憶體映射區，這些都是細節，這裡我們不做糾纏)。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　上圖是記憶體分布的模糊輪廓

　 由get_free_page或Kmalloc函數所分配的連續記憶體都陷於物理映射區域，所以它們返回的內核虛擬地址和實際物理地址僅僅是相差一個偏移量（PAGE_OFFSET），你可以很方便的將其轉化為物理記憶體地址，同時內核也提供了virt_to_phys（）函數將內核虛擬空間中的物理映射區地址轉化為物理地址。要知道，物理記憶體映射區中的地址與內核頁表是有序對應的，系統中的每個物理頁面都可以找到它對應的內核虛擬地址（在物理記憶體映射區中的）。

而vmalloc分配的地址則限於vmalloc_start與vmalloc_end之間。每一塊vmalloc分配的內核虛擬記憶體都對應一個vm_struct結構體（可別和vm_area_struct搞混，那可是進程虛擬記憶體區域的結構），不同的內核虛擬地址被4k大小的空閑區間隔，以防止越界——見下圖）。與進程虛擬地址的特性一樣，這些虛擬地址與物理記憶體沒有簡單的位移關係，必須通過內核頁表才可轉換為物理地址或物理頁。它們有可能尚未被映射，在發生缺頁時才真正分配物理頁面。

這裡給出一個小程式幫助大家認清上面幾種分配函數所對應的區域。

#include<linux/module.h>    #include<linux/slab.h>    #include<linux/vmalloc.h>    unsigned char *pagemem;    unsigned char *kmallocmem;    unsigned char *vmallocmem;    int init_module(void)    {     pagemem = get_free_page(0);     printk("<1>pagemem=%s",pagemem);     kmallocmem = kmalloc(100,0);     printk("<1>kmallocmem=%s",kmallocmem);     vmallocmem = vmalloc(1000000);     printk("<1>vmallocmem=%s",vmallocmem);    }    void cleanup_module(void)    {     free_page(pagemem);     kfree(kmallocmem);     vfree(vmallocmem);    }

實例

記憶體映射(mmap)是Linux作業系統的一個很大特色，它可以將系統記憶體映射到一個文件（設備）上，以便可以通過訪問文件內容來達到訪問記憶體的目的。這樣做的最大好處是提高了記憶體訪問速度，並且可以利用文件系統的介面編程（設備在Linux中作為特殊文件處理）訪問記憶體，降低了開發難度。許多設備驅動程式便是利用記憶體映射功能將用戶空間的一段地址關聯到設備記憶體上，無論何時，只要記憶體在分配的地址範圍內進行讀寫，實際上就是對設備記憶體的訪問。同時對設備文件的訪問也等同於對記憶體區域的訪問，也就是說，通過文件操作介面可以訪問記憶體。Linux中的X伺服器就是一個利用記憶體映射達到直接高速訪問影片卡記憶體的例子。

熟悉文件操作的朋友一定會知道file_operations結構中有mmap方法，在用戶執行mmap系統調用時，便會調用該方法來通過文件訪問記憶體——不過在調用文件系統mmap方法前，內核還需要處理分配記憶體區域（vma_struct）、建立頁表等工作。對於具體映射細節不作介紹了，需要強調的是,建立頁表可以採用remap_page_range方法一次建立起所有映射區的頁表，或利用vma_struct的nopage方法在缺頁時現場一頁一頁的建立頁表。第一種方法相比第二種方法簡單方便、速度快， 但是靈活性不高。一次調用所有頁表便定型了，不適用於那些需要現場建立頁表的場合——比如映射區需要擴展或下面我們例子中的情況。

我們這裡的實例希望利用記憶體映射，將系統內核中的一部分虛擬記憶體映射到用戶空間，以供應用程式讀取——你可利用它進行內核空間到用戶空間的大規模資訊傳輸。因此我們將試圖寫一個虛擬字元設備驅動程式，通過它將系統內核空間映射到用戶空間——將內核虛擬記憶體映射到用戶虛擬地址。從上一節已經看到Linux內核空間中包含兩種虛擬地址：一種是物理和邏輯都連續的物理記憶體映射虛擬地址；另一種是邏輯連續但非物理連續的vmalloc分配的記憶體虛擬地址。我們的例子程式將演示把vmalloc分配的內核虛擬地址映射到用戶地址空間的全過程。

程式里主要應解決兩個問題：

第一是如何將vmalloc分配的內核虛擬記憶體正確地轉化成物理地址？

因為記憶體映射先要獲得被映射的物理地址，然後才能將其映射到要求的用戶虛擬地址上。我們已經看到內核物理記憶體映射區域中的地址可以被內核函數virt_to_phys轉換成實際的物理記憶體地址，但對於vmalloc分配的內核虛擬地址無法直接轉化成物理地址，所以我們必須對這部分虛擬記憶體格外「照顧」——先將其轉化成內核物理記憶體映射區域中的地址，然後在用virt_to_phys變為物理地址。

轉化工作需要進行如下步驟：

a) 找到vmalloc虛擬記憶體對應的頁表，並尋找到對應的頁表項。

b) 獲取頁表項對應的頁面指針

c) 通過頁面得到對應的內核物理記憶體映射區域地址。

如下圖所示：

第二是當訪問vmalloc分配區時，如果發現虛擬記憶體尚未被映射到物理頁，則需要處理「缺頁異常」。因此需要我們實現記憶體區域中的nopaga操作，以能返回被映射的物理頁面指針，在我們的實例中就是返回上面過程中的內核物理記憶體映射區域中的地址。由於vmalloc分配的虛擬地址與物理地址的對應關係並非分配時就可確定，必須在缺頁現場建立頁表，因此這裡不能使用remap_page_range方法，只能用vma的nopage方法一頁一頁的建立。

程式組成

map_driver.c，它是以模組形式載入的虛擬字元驅動程式。該驅動負責將一定長的內核虛擬地址(vmalloc分配的)映射到設備文件上。其中主要的函數有——vaddress_to_kaddress（）負責對vmalloc分配的地址進行頁表解析,以找到對應的內核物理映射地址（kmalloc分配的地址）；map_nopage()負責在進程訪問一個當前並不存在的VMA頁時，尋找該地址對應的物理頁，並返回該頁的指針。

test.c 它利用上述驅動模組對應的設備文件在用戶空間讀取讀取內核記憶體。結果可以看到內核虛擬地址的內容（ok!），被顯示在了螢幕上。

執行步驟

編譯map_driver.c為map_driver.o模組,具體參數見Makefile

載入模組 ：insmod map_driver.o

生成對應的設備文件

1 在/proc/devices下找到map_driver對應的設備命和設備號：grep mapdrv /proc/devices

2 建立設備文件mknod mapfile c 254 0 （在我的系統里設備號為254）

利用maptest讀取mapfile文件，將取自內核的資訊列印到螢幕上。