轉: 內核是如何管理內存的
原文標題：How The Kernel Manages Your Memory
原文地址：http://duartes.org/gustavo/blog/
[注：本人水平有限，只好挑一些國外高手的精彩文章翻譯一下。一來自己複習，二來與大家分享。]
在仔細審視了進程的虛擬地址佈局之後，讓我們把目光轉向內核以及其管理用戶內存的機制。再次從gonzo圖示開始：
Linux進程在內核中是由task_struct的實例來表示的，即進程描述符。task_struct的mm字段指向內存描述符（memory descriptor），即mm_struct，一個程序的內存的執行期摘要。它存儲了上圖所示的內存段的起止位置，進程所使用的物理內存頁的數量（rss表示Resident Set Size），虛擬內存空間的使用量，以及其他信息。我們還可以在內存描述符中找到用於管理程序內存的兩個重要結構：虛擬內存區域集合（the set of virtual memory areas）及頁表（page table）。Gonzo的內存區域如下圖所示：
每一個虛擬內存區域（簡稱VMA）是一個連續的虛擬地址範圍；這些區域不會交疊。一個vm_area_struct的實例完備的描述了一個內存區域，包括它的起止地址，決定訪問權限和行爲的標誌位，還有vm_file字段，用於指出被映射的文件（如果有的話）。一個VMA如果沒有映射到文件，則是匿名的（anonymous）。除memory mapping段以外，上圖中的每一個內存段（如：堆，棧）都對應於一個單獨的VMA。這並不是強制要求，但在x86機器上經常如此。VMA並不關心它在哪一個段。
一個程序的VMA同時以兩種形式存儲在它的內存描述符中：一個是按起始虛擬地址排列的鏈表，保存在mmap字段；另一個是紅黑樹，根節點保存在mm_rb字段。紅黑樹使得內核可以快速的查找出給定虛擬地址所屬的內存區域。當你讀取文件/proc/pid_of_process/maps時，內核只須簡單的遍歷指定進程的VMA鏈表，並打印出每一項來即可。
在Windows中，EPROCESS塊可以粗略的看成是task_struct和mm_struct的組合。VMA在Windows中的對應物時虛擬地址描述符（Virtual Address Descriptor），或簡稱VAD；它們保存在平衡樹中（AVL tree）。你知道Windows和Linux最有趣的地方是什麼嗎？就是這些細小的不同點。
4GB虛擬地址空間被分割爲許多頁（page）。x86處理器在32位模式下所支持的頁面大小爲4KB，2MB和4MB。Linux和Windows都使用4KB大小的頁面來映射用戶部分的虛擬地址空間。第0-4095字節在第0頁，第4096-8191字節在第1頁，以此類推。VMA的大小必須是頁面大小的整數倍。下圖是以4KB分頁的3GB用戶空間：
處理器會依照頁表（page table）來將虛擬地址轉換到物理內存地址。每個進程都有屬於自己的一套頁表；一旦進程發生了切換，用戶空間的頁表也會隨之切換。Linux在內存描述符的pgd字段保存了一個指向進程頁表的指針。每一個虛擬內存頁在頁表中都有一個與之對應的頁表項（page table entry），簡稱PTE。它在普通的x86分頁機制下，是一個簡單的4字節記錄，如下圖所示：
Linux有一些函數可以用於讀取或設置PTE中的每一個標誌。P位告訴處理器虛擬頁面是否存在於（present）物理內存中。如果是0，訪問這個頁將觸發頁故障（page fault）。記住，當這個位是0時，內核可以根據喜好，隨意的使用其餘的字段。R/W標誌表示讀/寫；如果是0，頁面就是隻讀的。U/S標誌表示用戶/管理員；如果是0，則這個頁面只能被內核訪問。這些標誌用於實現只讀內存和保護內核空間。
D位和A位表示數據髒（dirty）和訪問過（accessed）。髒表示頁面被執行過寫操作，訪問過表示頁面被讀或被寫過。這兩個標誌都是粘滯的：處理器只會將它們置位，之後必須由內核來清除。最後，PTE還保存了對應該頁的起始物理內存地址，對齊於4KB邊界。PTE中的其他字段我們改日再談，比如物理地址擴展（Physical Address Extension）。
虛擬頁面是內存保護的最小單元，因爲頁內的所有字節都共享U/S和R/W標誌。然而，同樣的物理內存可以被映射到不同的頁面，甚至可以擁有不同的保護標誌。值得注意的是，在PTE中沒有對執行許可（execute permission）的設定。這就是爲什麼經典的x86分頁可以執行位於stack上的代碼，從而爲黑客利用堆棧溢出提供了便利（使用return-to-libc和其他技術，甚至可以利用不可執行的堆棧）。PTE缺少不可執行（no-execute）標誌引出了一個影響更廣泛的事實：VMA中的各種許可標誌可能會也可能不會被明確的轉換爲硬件保護。對此，內核可以盡力而爲，但始終受到架構的限制。
虛擬內存並不存儲任何東西，它只是將程序地址空間映射到底層的物理內存上，後者被處理器視爲一整塊來訪問，稱作物理地址空間（physical address space）。對物理內存的操作還與總線有點聯繫，好在我們可以暫且忽略這些並假設物理地址範圍以字節爲單位遞增，從０到最大可用內存數。這個物理地址空間被內核分割爲一個個頁幀（page frame）。處理器並不知道也不關心這些幀，然而它們對內核至關重要，因爲頁幀是物理內存管理的最小單元。Linux和Windows在32位模式下，都使用4KB大小的頁幀；以一個擁有2GB RAM的機器爲例：
在Linux中，每一個頁幀都由一個描述符和一些標誌所跟蹤。這些描述符合在一起，記錄了計算機內的全部物理內存；可以隨時知道每一個頁幀的準確狀態。物理內存是用buddy memory allocation技術來管理的，因此如果一個頁幀可被buddy 系統分配，則它就是可用的（free）。一個被分配了的頁幀可能是匿名的（anonymous），保存着程序數據；也可能是頁緩衝的（page cache），保存着一個文件或塊設備的數據。還有其他一些古怪的頁幀使用形式，但現在先不必考慮它們。Windows使用一個類似的頁幀編號（Page Frame Number簡稱PFN）數據庫來跟蹤物理內存。
讓我們把虛擬地址區域，頁表項，頁幀放到一起，看看它們到底是怎麼工作的。下圖是一個用戶堆的例子：
藍色矩形表示VMA範圍內的頁，箭頭表示頁表項將頁映射到頁幀上。一些虛擬頁並沒有箭頭；這意味着它們對應的PTE的存在位（Present flag）爲0。形成這種情況的原因可能是這些頁還沒有被訪問過，或者它們的內容被系統換出了（swap out）。無論那種情況，對這些頁的訪問都會導致頁故障（page fault），即使它們處在VMA之內。VMA和頁表的不一致看起來令人奇怪，但實際經常如此。
一個VMA就像是你的程序和內核之間的契約。你請求去做一些事情（如：內存分配，文件映射等），內核說"行"，並創建或更新適當的VMA。但它並非立刻就去完成請求，而是一直等到出現了頁故障纔會真正去做。內核就是一個懶惰，騙人的敗類；這是虛擬內存管理的基本原則。它對大多數情況都適用，有些比較熟悉，有些令人驚訝，但這個規則就是這樣：VMA記錄了雙方商定做什麼，而PTE反映出懶惰的內核實際做了什麼。這兩個數據結構共同管理程序的內存；都扮演着解決頁故障，釋放內存，換出內存（swapping memory out）等等角色。讓我們看一個簡單的內存分配的例子：
當程序通過brk()系統調用請求更多的內存時，內核只是簡單的更新堆的VMA，然後說搞好啦。其實此時並沒有頁幀被分配，新的頁也並沒有出現於物理內存中。一旦程序試圖訪問這些頁，處理器就會報告頁故障，並調用do_page_fault()。它會通過調用find_vma()去搜索哪一個VMA含蓋了產生故障的虛擬地址。如果找到了，還會根據VMA上的訪問許可來比對檢查訪問請求（讀或寫）。如果沒有合適的VMA，也就是說內存訪問請求沒有與之對應的合同，進程就會被處以段錯誤（Segmentation Fault）的罰單。
當一個VMA被找到後，內核必須處理這個故障，方式是察看PTE的內容以及VMA的類型。在我們的例子中，PTE顯示了該頁並不存在。事實上，我們的PTE是完全空白的（全爲0），在Linux中意味着虛擬頁還沒有被映射。既然這是一個匿名的VMA，我們面對的就是一個純粹的RAM事務，必須由do_anonymous_page()處理，它會分配一個頁幀並生成一個PTE，將出故障的虛擬頁映射到那個剛剛分配的頁幀上。
事情還可能有些不同。被換出的頁所對應的PTE，例如，它的Present標誌是0但並不是空白的。相反，它記錄了頁面內容在交換系統中的位置，這些內容必須從磁盤讀取出來並通過do_swap_page()加載到一個頁幀當中，這就是所謂的major fault。
至此我們走完了"內核的用戶內存管理"之旅的前半程。在下一篇文章中，我們將把文件的概念也混進來，從而建立一個內存基礎知識的完成畫面，並瞭解其對系統性能的影響。
參考:
http://blog.csdn.net/drshenlei/article/details/4350928
轉: 頁面緩存-內存與文件的那些事
原文標題：Page Cache, the Affair Between Memory and Files
原文地址：http://duartes.org/gustavo/blog/
[注：本人水平有限，只好挑一些國外高手的精彩文章翻譯一下。一來自己複習，二來與大家分享。]
上次我們考察了內核如何爲一個用戶進程管理虛擬內存，但是沒有涉及文件及I/O。這次我們的討論將涵蓋非常重要且常被誤解的文件與內存間關係的問題，以及它對系統性能的影響。
提到文件，操作系統必須解決兩個重要的問題。首先是硬盤驅動器的存取速度緩慢得令人頭疼（相對於內存而言），尤其是磁盤的尋道性能。第二個是要滿足'一次性加載文件內容到物理內存並在程序間共享'的需求。如果你使用進程瀏覽器翻看Windows進程，就會發現大約15MB的共享DLL被加載進了每一個進程。我目前的Windows系統就運行了100個進程，如果沒有共享機制，那將消耗大約1.5GB的物理內存僅僅用於存放公用DLL。這可不怎麼好。同樣的，幾乎所有的Linux程序都需要ld.so和libc，以及其它的公用函數庫。
令人愉快的是，這兩個問題可以被一石二鳥的解決：頁面緩存（page cache），內核用它保存與頁面同等大小的文件數據塊。爲了展示頁面緩存，我需要祭出一個名叫render的Linux程序，它會打開一個scene.dat文件，每次讀取其中的512字節，並將這些內容保存到一個建立在堆上的內存塊中。首次的讀取是這樣的：
在讀取了12KB以後，render的堆以及相關的頁幀情況如下：
這看起來很簡單，但還有很多事情會發生。首先，即使這個程序只調用了常規的read函數，此時也會有三個 4KB的頁幀存儲在頁面緩存當中，它們持有scene.dat的一部分數據。儘管有時這令人驚訝，但的確所有的常規文件I/O都是通過頁面緩存來進行的。在x86 Linux裏，內核將文件看作是4KB大小的數據塊的序列。即使你只從文件讀取一個字節，包含此字節的整個4KB數據塊都會被讀取，並放入到頁面緩存當中。這樣做是有道理的，因爲磁盤的持續性數據吞吐量很不錯，而且一般說來，程序對於文件中某區域的讀取都不止幾個字節。頁面緩存知道每一個4KB數據塊在文件中的對應位置，如上圖所示的#0, #1等等。與Linux的頁面緩存類似，Windows使用256KB的views。
不幸的是，在一個普通的文件讀取操作中，內核必須複製頁面緩存的內容到一個用戶緩衝區中，這不僅消耗CPU時間，傷害了CPU cache的性能，還因爲存儲了重複信息而浪費物理內存。如上面每張圖所示，scene.dat的內容被保存了兩遍，而且程序的每個實例都會保存一份。至此，我們緩和了磁盤延遲的問題，但卻在其餘的每個問題上慘敗。內存映射文件（memory-mapped files）將引領我們走出混亂：
當你使用文件映射的時候，內核將你的程序的虛擬內存頁直接映射到頁面緩存上。這將導致一個顯著的性能提升：《Windows系統編程》指出常規的文件讀取操作運行時性能改善30%以上；《Unix環境高級編程》指出類似的情況也發生在Linux和Solaris系統上。你還可能因此而節省下大量的物理內存，這依賴於你的程序的具體情況。
和以前一樣，提到性能，實際測量纔是王道，但是內存映射的確值得被程序員們放入工具箱。相關的API也很漂亮，它提供了像訪問內存中的字節一樣的方式來訪問一個文件，不需要你多操心，也不犧牲代碼的可讀性。回憶一下地址空間、還有那個在Unix類系統上關於mmap的實驗，Windows下的CreateFileMapping及其在高級語言中的各種可用封裝。當你映射一個文件時，它的內容並不是立刻就被全部放入內存的，而是依賴頁故障（page fault）按需讀取。在獲取了一個包含所需的文件數據的頁幀後，對應的故障處理函數會將你的虛擬內存頁映射到頁面緩存上。如果所需內容不在緩存當中，此過程還將包含磁盤I/O操作。
現在給你出一個流行的測試題。想象一下，在最後一個render程序的實例退出之時，那些保存了scene.dat的頁面緩存會被立刻清理嗎？人們通常會這樣認爲，但這是個壞主意。如果你仔細想想，我們經常會在一個程序中創建一個文件，退出，緊接着在第二個程序中使用這個文件。頁面緩存必須能處理此類情況。如果你再多想想，內核何必總是要捨棄頁面緩存中的內容呢？記住，磁盤比RAM慢5個數量級，因此一個頁面緩存的命中（hit）就意味着巨大的勝利。只要還有足夠的空閒物理內存，緩存就應該儘可能保持滿狀態。所以它與特定的進程並不相關，而是一個系統級的資源。如果你一週前運行過render，而此時scene.dat還在緩存當中，那真令人高興。這就是爲什麼內核緩存的大小會穩步增加，直到緩存上限。這並非因爲操作系統是破爛貨，吞噬你的RAM，事實上這是種好的行爲，反而釋放物理內存纔是一種浪費。緩存要利用得越充分越好。
由於使用了頁面緩存體系結構，當一個程序調用write()時，相關的字節被簡單的複製到頁面緩存中，並且將頁面標記爲髒的（dirty）。磁盤I/O一般不會立刻發生，因此你的程序的執行不會被打斷去等待磁盤設備。這樣做的缺點是，如果此時計算機死機，那麼你寫入的數據將不會被記錄下來。因此重要的文件，比如數據庫事務記錄必須被fsync() （但是還要小心磁盤控制器的緩存）。另一方面，讀取操作一般會打斷你的程序直到準備好所需的數據。內核通常採用積極加載（eager loading）的方式來緩解這個問題。以提前讀取（read ahead）爲例，內核會預先加載一些頁到頁面緩存，並期待你的讀取操作。通過提示系統即將對文件進行的是順序還是隨機讀取操作（參看madvise(), readahead(), Windows緩存提示），你可以幫助內核調整它的積極加載行爲。Linux的確會對內存映射文件進行預取，但我不太確定Windows是否也如此。最後需要一提的是，你還可以通過在Linux中使用O_DIRECT或在Windows中使用NO_BUFFERING來繞過頁面緩存，有些數據庫軟件就是這麼做的。
一個文件映射可以是私有的（private）或共享的（shared）。這裏的區別只有在更改（update）內存中的內容時纔會顯現出來：在私有映射中，更改並不會被提交到磁盤或對其他進程可見，而這在共享的映射中就會發生。內核使用寫時拷貝（copy on write）技術，通過頁表項（page table entries），實現私有映射。在下面的例子中，render和另一個叫render3d的程序（我是不是很有創意？）同時私有映射了scene.dat。隨後render改寫了映射到此文件的虛擬內存區域：
上圖所示的只讀的頁表項並不意 味着映射是隻讀的，它們只是內核耍的小把戲，用於共享物理內存直到可能的最後一刻。你會發現'私有'一詞是多麼的不恰當，你只需記住它只在數據發生更改時 起作用。此設計所帶來的一個結果就是，一個以私有方式映射文件的虛擬內存頁可以觀察到其他進程對此文件的改動，只要之前對這個內存頁進行的都是讀取操作。 一旦發生過寫時拷貝，就不會再觀察到其他進程對此文件的改動了。此行爲不是內核提供的，而是在x86系統上就會如此。另外，從API的角度來說，這也是合理的。與此相反，共享映射只是簡單的映射到頁面緩存，僅此而已。對頁面的所有更改操作對其他進程都可見，而且最終會執行磁盤操作。最後，如果此共享映射是隻讀的，那麼頁故障將觸發段錯誤（segmentation fault）而不是寫時拷貝。
被動態加載的函數庫通過文件映射機制放入到你的程序的地址空間中。這裏沒有任何特別之處，同樣是採用私有文件映射，跟提供給你調用的常規API別無二致。下面的例子展示了兩個運行中的render程序的一部分地址空間，還有物理內存。它將我們之前看到的概念都聯繫在了一起。
至此我們完成了內存基礎知識的三部曲系列。我希望這個系列對您有用，並在您頭腦中建立一個好的操作系統模型。
參考: