LINUX內存管理【轉】

轉自:http://kerneltravel.net/blog/2020/memory_management/#

2020年6月7日 | 由 Jinrong | 11200字 | 閱讀大約需要23分鐘 | 歸檔於 內存管理 |

摘要

本章首先以應用程序開發者的角度審視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 mem\n");
    printf("Text location:\n");
    printf("\tAddress of main(Code Segment):%p\n",main);
    printf("____________________________\n");
    int stack_var0=2;
    printf("Stack Location:\n");
    printf("\tInitial end of stack:%p\n",&stack_var0);
    int stack_var1=3;
    printf("\tnew end of stack:%p\n",&stack_var1);
    printf("____________________________\n");
    printf("Data Location:\n");
    printf("\tAddress of data_var(Data Segment):%p\n",&data_var0);
    static int data_var1=4;
    printf("\tNew end of data_var(Data Segment):%p\n",&data_var1);
    printf("____________________________\n");
    printf("BSS Location:\n");
    printf("\tAddress of bss_var:%p\n",&bss_var);
    printf("____________________________\n");
    char *b = sbrk((ptrdiff_t)0);
    printf("Heap Location:\n");
    printf("\tInitial end of heap:%p\n",b);
    brk(b+4);
    b=sbrk((ptrdiff_t)0);
	printf("\tNew end of heap:%p\n",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的線性虛擬空間,用戶所看到和接觸到的都是該虛擬地址,無法看到實際的物理內存地址。利用這種虛擬地址不但能起到保護操作系統的效果(用戶不能直接訪問物理內存),而且更重要的是,用戶程序可使用比實際物理內存更大的地址空間(具體的原因請看硬件基礎部分)。

在討論進程空間細節前,這裏先要澄清下面幾個問題:

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

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

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

進程內存管理

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

如果你要查看某個進程佔用的內存區域,可以使用命令cat /proc//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分配的內核虛擬內存位於不同的區間,不會重疊。因爲內核虛擬空間被分區管理,各司其職。進程空間地址分佈從0到3G(其實是到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文件,將取自內核的信息打印到屏幕上。

全部程序下載 mmap.tar (感謝Martin Frey,該程序的主體出自他的靈感)


[1] 靜態分配內存就是編譯器在編譯程序的時候根據源程序來分配內存. 動態分配內存就是在程序編譯之後, 運行時調用運行時刻庫函數來分配內存的. 靜態分配由於是在程序運行之前,所以速度快, 效率高, 但是侷限性大. 動態分配在程序運行時執行, 所以速度慢, 但靈活性高.

[2]術語"BSS"已經有些年頭了,它是block started by symbol的縮寫。因爲未初始化的變量沒有對應的值,所以並不需要存儲在可執行對象中。但是因爲C標準強制規定未初始化的全局變量要被賦予特殊的默認值(基本上是0值),所以內核要從可執行代碼裝入變量(未賦值的)到內存中,然後將零頁映射到該片內存上,於是這些未初始化變量就被賦予了0值。這樣做避免了在目標文件中進行顯式地初始化,減少空間浪費(來自《Linux內核開發》)

[3] 還有些情況必須要求內存連續,比如DMA傳輸中使用的內存,由於不涉及頁機制所以必須連續分配。

[4] 這種存儲池的思想在計算機科學裏廣泛應用,比如數據庫連接池、內存訪問池等等。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章