每個程式設計師都應該瞭解的“虛擬記憶體”知識

英文原文：Memory part 3: Virtual Memory 來源：oschina

[編輯注：本文是Ulrich Drepper的“每個程式設計師應該瞭解的記憶體方面的知識”文章的第三部分；這一部分談論了虛擬記憶體，特別是TLB效能。沒有閱讀第1部分和第2部分的人可能現在就想讀一讀了。和往常一樣，請將排字錯誤報告之類傳送到lwn@lwn.net，而不要傳送到這裡的評論。]

4 虛擬記憶體

處理器的虛擬記憶體子系統為每個程式實現了虛擬地址空間。這讓每個程式認為它在系統中是獨立的。虛擬記憶體的優點列表別的地方描述的非常詳細，所以這裡就不重複了。本節集中在虛擬記憶體的實際的實現細節，和相關的成本。

虛擬地址空間是由CPU的記憶體管理單元(MMU)實現的。OS必須填充頁表資料結構，但大多數CPU自己做了剩下的工作。這事實上是一個相當複雜的機制；最好的理解它的方法是引入資料結構來描述虛擬地址空間。

由MMU進行地址翻譯的輸入地址是虛擬地址。通常對它的值很少有限制 — 假設還有一點的話。 虛擬地址在32位系統中是32位的數值，在64位系統中是64位的數值。在一些系統，例如x86和x86-64，使用的地址實際上包含了另一個層次的間接定址：這些結構使用分段，這些分段只是簡單的給每個邏輯地址加上位移。我們可以忽略這一部分的地址產生，它不重要，不是程式設計師非常關心的記憶體處理效能方面的東西。{x86的分段限制是與效能相關的，但那是另一回事了}

4.1 最簡單的地址轉換

有趣的地方在於由虛擬地址到實體地址的轉換。MMU可以在逐頁的基礎上重新對映地址。就像地址快取排列的時候，虛擬地址被分割為不同的部分。這些部分被用來做多個表的索引，而這些表是被用來建立最終實體地址用的。最簡單的模型是隻有一級表。

Figure 4.1: 1-Level Address Translation

圖 4.1 顯示了虛擬地址的不同部分是如何使用的。高位元組部分是用來選擇一個頁目錄的條目；那個目錄中的每個地址可以被OS分別設定。頁目錄條目決定了實體記憶體頁的地址；頁面中可以有不止一個條目指向同樣的實體地址。完整的記憶體實體地址是由頁目錄獲得的頁地址和虛擬地址低位元組部分合並起來決定的。頁目錄條目還包含一些附加的頁面資訊，如訪問許可權。

頁目錄的資料結構儲存在記憶體中。OS必須分配連續的實體記憶體，並將這個地址範圍的基地址存入一個特殊的暫存器。然後虛擬地址的適當的位被用來作為頁目錄的索引，這個頁目錄事實上是目錄條目的列表。

作為一個具體的例子，這是 x86機器4MB分頁設計。虛擬地址的位移部分是22位大小，足以定位一個4M頁內的每一個位元組。虛擬地址中剩下的10位指定頁目錄中1024個條目的一個。每個條目包括一個10位的4M頁內的基地址，它與位移結合起來形成了一個完整的32位地址。

4.2 多級頁表

4MB的頁不是規範，它們會浪費很多記憶體，因為OS需要執行的許多操作需要記憶體頁的佇列。對於4kB的頁（32位機器的規範，甚至通常是64位機器的規範），虛擬地址的位移部分只有12位大小。這留下了20位作為頁目錄的指標。具有2²⁰個條目的表是不實際的。即使每個條目只要4位元，這個表也要4MB大小。由於每個程式可能具有其唯一的頁目錄，因為這些頁目錄許多系統中實體記憶體被繫結起來。

解決辦法是用多級頁表。然後這些就能表示一個稀疏的大的頁目錄，目錄中一些實際不用的區域不需要分配記憶體。因此這種表示更緊湊，使它可能為記憶體中的很多程式使用頁表而並不太影響效能。.

今天最複雜的頁表結構由四級構成。圖4.2顯示了這樣一個實現的原理圖。

Figure 4.2: 4-Level Address Translation

在這個例子中，虛擬地址被至少分為五個部分。其中四個部分是不同的目錄的索引。被引用的第4級目錄使用CPU中一個特殊目的的暫存器。第4級到第2級目錄的內容是對次低一級目錄的引用。如果一個目錄條目標識為空，顯然就是不需要指向任何低一級的目錄。這樣頁表樹就能稀疏和緊湊。正如圖4.1，第1級目錄的條目是一部分實體地址，加上像訪問許可權的輔助資料。

為了決定相對於虛擬地址的實體地址，處理器先決定最高階目錄的地址。這個地址一般儲存在一個暫存器。然後CPU取出虛擬地址中相對於這個目錄的索引部分，並用那個索引選擇合適的條目。這個條目是下一級目錄的地址，它由虛擬地址的下一部分索引。處理器繼續直到它到達第1級目錄，那裡那個目錄條目的值就是實體地址的高位元組部分。實體地址在加上虛擬地址中的頁面位移之後就完整了。這個過程稱為頁面樹遍歷。一些處理器（像x86和x86-64）在硬體中執行這個操作，其他的需要OS的協助。

系統中執行的每個程式可能需要自己的頁表樹。有部分共享樹的可能，但是這相當例外。因此如果頁表樹需要的記憶體儘可能小的話將對效能與可擴充套件性有利。理想的情況是將使用的記憶體緊靠著放在虛擬地址空間；但實際使用的實體地址不影響。一個小程式可能只需要第2，3，4級的一個目錄和少許第1級目錄就能應付過去。在一個採用4kB頁面和每個目錄512條目的x86-64機器上，這允許用4級目錄對2MB定位（每一級一個）。1GB連續的記憶體可以被第2到第4級的一個目錄和第1級的512個目錄定位。

但是，假設所有記憶體可以被連續分配是太簡單了。由於複雜的原因，大多數情況下，一個程式的棧與堆的區域是被分配在地址空間中非常相反的兩端。這樣使得任一個區域可以根據需要儘可能的增長。這意味著最有可能需要兩個第2級目錄和相應的更多的低一級的目錄。

但即使這也不常常匹配現在的實際。由於安全的原因，一個可執行的（程式碼，資料，堆，棧，動態共享物件，aka共享庫）不同的部分被對映到隨機的地址[未選中的]。隨機化延伸到不同部分的相對位置；那意味著一個程式使用的不同的記憶體範圍，遍佈於虛擬地址空間。通過對隨機的地址位數採用一些限定，範圍可以被限制，但在大多數情況下，這當然不會讓一個程式只用一到兩個第2和第3級目錄執行。

如果效能真的遠比安全重要，隨機化可以被關閉。OS然後通常是在虛擬記憶體中至少連續的裝載所有的動態共享物件(DSO)。

4.3 優化頁表訪問

頁表的所有資料結構都儲存在主存中；在那裡OS建造和更新這些表。當一個程式建立或者一個頁表變化，CPU將被通知。頁表被用來解決每個虛擬地址到實體地址的轉換，用上面描述的頁表遍歷方式。更多有關於此：至少每一級有一個目錄被用於處理虛擬地址的過程。這需要至多四次記憶體訪問（對一個執行中的程式的單次訪問來說），這很慢。有可能像普通資料一樣處理這些目錄表條目，並將他們快取在L1d,L2等等，但這仍然非常慢。

從虛擬記憶體的早期階段開始，CPU的設計者採用了一種不同的優化。簡單的計算顯示，只有將目錄表條目儲存在L1d和更高階的快取，才會導致可怕的效能問題。每個絕對地址的計算，都需要相對於頁表深度的大量的L1d訪問。這些訪問不能並行，因為它們依賴於前面查詢的結果。在一個四級頁表的機器上，這種單線性將 至少至少需要12次迴圈。再加上L1d的非命中的可能性，結果是指令流水線沒有什麼能隱藏的。額外的L1d訪問也消耗了珍貴的快取頻寬。

所以，替代於只是快取目錄表條目，物理頁地址的完整的計算結果被快取了。因為同樣的原因，程式碼和資料快取也工作起來，這樣的地址計算結果的快取是高效的。由於虛擬地址的頁面位移部分在物理頁地址的計算中不起任何作用，只有虛擬地址的剩餘部分被用作快取的標籤。根據頁面大小這意味著成百上千的指令或資料物件共享同一個標籤，因此也共享同一個實體地址字首。

儲存計算數值的快取叫做旁路轉換快取(TLB)。因為它必須非常的快，通常這是一個小的快取。現代CPU像其它快取一樣，提供了多級TLB快取；越高階的快取越大越慢。小號的L1級TLB通常被用來做全相聯映像快取，採用LRU回收策略。最近這種快取大小變大了，而且在處理器中變得集相聯。其結果之一就是，當一個新的條目必須被新增的時候，可能不是最久的條目被回收於替換了。

正如上面提到的，用來訪問TLB的標籤是虛擬地址的一個部分。如果標籤在快取中有匹配，最終的實體地址將被計算出來，通過將來自虛擬地址的頁面位移地址加到快取值的方式。這是一個非常快的過程；也必須這樣，因為每條使用絕對地址的指令都需要實體地址，還有在一些情況下，因為使用實體地址作為關鍵字的L2查詢。如果TLB查詢未命中，處理器就必須執行一次頁表遍歷；這可能代價非常大。

通過軟體或硬體預取程式碼或資料，會在地址位於另一頁面時，暗中預取TLB的條目。硬體預取不可能允許這樣，因為硬體會初始化非法的頁面表遍歷。因此程式設計師不能依賴硬體預取機制來預取TLB條目。它必須使用預取指令明確的完成。就像資料和指令快取，TLB可以表現為多個等級。正如資料快取，TLB通常表現為兩種形式：指令TLB(ITLB)和資料TLB(DTLB)。高階的TLB像L2TLB通常是統一的，就像其他的快取情形一樣。

4.3.1 使用TLB的注意事項

TLB是以處理器為核心的全域性資源。所有執行於處理器的執行緒與程式使用同一個TLB。由於虛擬到實體地址的轉換依賴於安裝的是哪一種頁表樹，如果頁表變化了，CPU不能盲目的重複使用快取的條目。每個程式有一個不同的頁表樹（不算在同一個程式中的執行緒），核心與記憶體管理器VMM(管理程式)也一樣，如果存在的話。也有可能一個程式的地址空間佈局發生變化。有兩種解決這個問題的辦法：

• 當頁表樹變化時TLB重新整理。
• TLB條目的標籤附加擴充套件並唯一標識其涉及的頁表樹

第一種情況，只要執行一個上下文切換TLB就被重新整理。因為大多數OS中，從一個執行緒/程式到另一個的切換需要執行一些核心程式碼，TLB重新整理被限制進入或離開核心地址空間。在虛擬化的系統中，當核心必須呼叫記憶體管理器VMM和返回的時候，這也會發生。如果核心和/或記憶體管理器沒有使用虛擬地址，或者當程式或核心呼叫系統/記憶體管理器時，能重複使用同一個虛擬地址，TLB必須被重新整理。當離開核心或記憶體管理器時，處理器繼續執行一個不同的程式或核心。

重新整理TLB高效但昂貴。例如，當執行一個系統呼叫，觸及的核心程式碼可能僅限於幾千條指令，或許少許新頁面（或一個大的頁面，像某些結構的Linux的就是這樣）。這個工作將替換觸及頁面的所有TLB條目。對Intel帶128ITLB和256DTLB條目的Core2架構，完全的重新整理意味著多於100和200條目（分別的）將被不必要的重新整理。當系統呼叫返回同一個程式，所有那些被重新整理的TLB條目可能被再次用到，但它們沒有了。核心或記憶體管理器常用的程式碼也一樣。每條進入核心的條目上，TLB必須擦去再裝，即使核心與記憶體管理器的頁表通常不會改變。因此理論上說，TLB條目可以被保持一個很長時間。這也解釋了為什麼現在處理器中的TLB快取都不大：程式很有可能不會執行時間長到裝滿所有這些條目。

當然事實逃脫不了CPU的結構。對快取重新整理優化的一個可能的方法是單獨的使TLB條目失效。例如，如果核心程式碼與資料落於一個特定的地址範圍，只有落入這個地址範圍的頁面必須被清除出TLB。這隻需要比較標籤，因此不是很昂貴。在部分地址空間改變的場合，例如對去除記憶體頁的一次呼叫，這個方法也是有用的，

更好的解決方法是為TLB訪問擴充套件標籤。如果除了虛擬地址的一部分之外，一個唯一的對應每個頁表樹的標識（如一個程式的地址空間）被新增，TLB將根本不需要完全重新整理。核心，記憶體管理程式，和獨立的程式都可以有唯一的標識。這種場景唯一的問題在於，TLB標籤可以獲得的位數異常有限，但是地址空間的位數卻不是。這意味著一些標識的再利用是有必要的。這種情況發生時TLB必須部分重新整理（如果可能的話）。所有帶有再利用標識的條目必須被重新整理，但是希望這是一個非常小的集合。

當多個程式執行在系統中時，這種擴充套件的TLB標籤具有一般優勢。如果每個可執行程式對記憶體的使用（因此TLB條目的使用）做限制，程式最近使用的TLB條目,當其再次列入計劃時，有很大機會仍然在TLB。但還有兩個額外的優勢：

1. 特殊的地址空間，像核心和記憶體管理器使用的那些，經常僅僅進入一小段時間；之後控制經常返回初始化此次呼叫的地址空間。沒有標籤，就有兩次TLB重新整理操作。有標籤，呼叫地址空間快取的轉換地址將被儲存，而且由於核心與記憶體管理器地址空間根本不會經常改變TLB條目，系統呼叫之前的地址轉換等等可以仍然使用。
2. 當同一個程式的兩個執行緒之間切換時，TLB重新整理根本就不需要。雖然沒有擴充套件TLB標籤時，進入核心的條目會破壞第一個執行緒的TLB的條目。

有些處理器在一些時候實現了這些擴充套件標籤。AMD給帕西菲卡（Pacifica）虛擬化擴充套件引入了一個1位的擴充套件標籤。在虛擬化的上下文中，這個1位的地址空間ID（ASID）被用來從客戶域區別出記憶體管理程式的地址空間。這使得OS能夠避免在每次進入記憶體管理程式的時候（例如為了處理一個頁面錯誤）重新整理客戶的TLB條目，或者當控制回到客戶時重新整理記憶體管理程式的TLB條目。這個架構未來會允許使用更多的位。其它主流處理器很可能會隨之適應並支援這個功能。

4.3.2 影響TLB效能

有一些因素會影響TLB效能。第一個是頁面的大小。顯然頁面越大，裝進去的指令或資料物件就越多。所以較大的頁面大小減少了所需的地址轉換總次數，即需要更少的TLB快取條目。大多數架構允許使用多個不同的頁面尺寸；一些尺寸可以並存使用。例如，x86/x86-64處理器有一個普通的4kB的頁面尺寸，但它們也可以分別用4MB和2MB頁面。IA-64 和 PowerPC允許如64kB的尺寸作為基本的頁面尺寸。

然而，大頁面尺寸的使用也隨之帶來了一些問題。用作大頁面的記憶體範圍必須是在實體記憶體中連續的。如果實體記憶體管理的單元大小升至虛擬記憶體頁面的大小，浪費的記憶體數量將會增長。各種記憶體操作（如載入可執行檔案）需要頁面邊界對齊。這意味著平均每次對映浪費了實體記憶體中頁面大小的一半。這種浪費很容易累加；因此它給實體記憶體分配的合理單元大小劃定了一個上限。

在x86-64結構中增加單元大小到2MB來適應大頁面當然是不實際的。這是一個太大的尺寸。但這轉而意味著每個大頁面必須由許多小一些的頁面組成。這些小頁面必須在實體記憶體中連續。以4kB單元頁面大小分配2MB連續的實體記憶體具有挑戰性。它需要找到有512個連續頁面的空閒區域。在系統執行一段時間並且實體記憶體開始碎片化以後，這可能極為困難（或者不可能）

因此在Linux中有必要在系統啟動的時候，用特別的Huge TLBfs檔案系統，預分配這些大頁面。一個固定數目的物理頁面被保留，以單獨用作大的虛擬頁面。這使可能不會經常用到的資源捆綁留下來。它也是一個有限的池；增大它一般意味著要重啟系統。儘管如此，大頁面是進入某些局面的方法，在這些局面中效能具有保險性，資源豐富，而且麻煩的安裝不會成為大的妨礙。資料庫伺服器就是一個例子。

增大最小的虛擬頁面大小（正如選擇大頁面的相反面）也有它的問題。記憶體對映操作（例如載入應用）必須確認這些頁面大小。不可能有更小的對映。對大多數架構來說，一個可執行程式的各個部分位置有一個固定的關係。如果頁面大小增加到超過了可執行程式或DSO(Dynamic Shared Object)建立時考慮的大小，載入操作將無法執行。腦海裡記得這個限制很重要。圖4.3顯示了一個ELF二進位制的對齊需求是如何決定的。它編碼在ELF程式頭部。

Figure 4.3: ELF 程式頭表明了對齊需求

在這個例子中，一個x86-64二進位制，它的值為0x200000 = 2,097,152 = 2MB，符合處理器支援的最大頁面尺寸。

使用較大記憶體尺寸有第二個影響：頁表樹的級數減少了。由於虛擬地址相對於頁面位移的部分增加了，需要用來在頁目錄中使用的位，就沒有剩下許多了。這意味著當一個TLB未命中時，需要做的工作數量減少了。

超出使用大頁面大小，它有可能減少移動資料時需要同時使用的TLB條目數目，減少到數頁。這與一些上面我們談論的快取使用的優化機制類似。只有現在對齊需求是巨大的。考慮到TLB條目數目如此小，這可能是一個重要的優化。

4.4 虛擬化的影響

OS映像的虛擬化將變得越來越流行；這意味著另一個層次的記憶體處理被加入了想象。程式（基本的隔間）或者OS容器的虛擬化，因為只涉及一個OS而沒有落入此分類。類似Xen或KVM的技術使OS映像能夠獨立執行 — 有或者沒有處理器的協助。這些情形下，有一個單獨的軟體直接控制實體記憶體的訪問。

圖 4.4: Xen 虛擬化模型

對Xen來說（見圖4.4），Xen VMM(Xen記憶體管理程式)就是那個軟體。但是，VMM沒有自己實現許多硬體的控制，不像其他早先的系統（包括Xen VMM的第一個版本）的VMM，記憶體以外的硬體和處理器由享有特權的Dom0域控制。現在，這基本上與沒有特權的DomU核心一樣，就記憶體處理方面而言，它們沒有什麼不同。這裡重要的是，VMM自己分發實體記憶體給Dom0和DomU核心，然後就像他們是直接執行在一個處理器上一樣，實現通常的記憶體處理

為了實現完成虛擬化所需的各個域之間的分隔，Dom0和DomU核心中的記憶體處理不具有無限制的實體記憶體訪問許可權。VMM不是通過分發獨立的物理頁並讓客戶OS處理地址的方式來分發記憶體；這不能提供對錯誤或欺詐客戶域的防範。替代的，VMM為每一個客戶域建立它自己的頁表樹，並且用這些資料結構分發記憶體。好處是對頁表樹管理資訊的訪問能得到控制。如果程式碼沒有合適的特權，它不能做任何事。 在虛擬化的Xen支援中，這種訪問控制已被開發，不管使用的是引數的或硬體的（又名全）虛擬化。客戶域以意圖上與引數的和硬體的虛擬化極為相似的方法，給每個程式建立它們的頁表樹。每當客戶OS修改了VMM呼叫的頁表，VMM就會用客戶域中更新的資訊去更新自己的影子頁表。這些是實際由硬體使用的頁表。顯然這個過程非常昂貴：每次對頁表樹的修改都需要VMM的一次呼叫。而沒有虛擬化時記憶體對映的改變也不便宜，它們現在變得甚至更昂貴。 考慮到從客戶OS的變化到VMM以及返回，其本身已經相當昂貴，額外的代價可能真的很大。這就是為什麼處理器開始具有避免建立影子頁表的額外功能。這樣很好不僅是因為速度的問題，而且它減少了VMM消耗的記憶體。Intel有擴充套件頁表(EPTs)，AMD稱之為巢狀頁表(NPTs)。基本上兩種技術都具有客戶OS的頁表，來產生虛擬的實體地址。然後通過每個域一個EPT/NPT樹的方式，這些地址會被進一步轉換為真實的實體地址。這使得可以用幾乎非虛擬化情境的速度進行記憶體處理，因為大多數用來記憶體處理的VMM條目被移走了。它也減少了VMM使用的記憶體，因為現在一個域（相對於程式）只有一個頁表樹需要維護。 額外的地址轉換步驟的結果也儲存於TLB。那意味著TLB不儲存虛擬實體地址，而替代以完整的查詢結果。已經解釋過AMD的帕西菲卡擴充套件為了避免TLB重新整理而給每個條目引入ASID。ASID的位數在最初版本的處理器擴充套件中是一位；這正好足夠區分VMM和客戶OS。Intel有服務同一個目的的虛擬處理器ID(VPIDs)，它們只有更多位。但對每個客戶域VPID是固定的，因此它不能標記單獨的程式，也不能避免TLB在那個級別重新整理。

對虛擬OS，每個地址空間的修改需要的工作量是一個問題。但是還有另一個內在的基於VMM虛擬化的問題：沒有什麼辦法處理兩層的記憶體。但記憶體處理很難（特別是考慮到像NUMA一樣的複雜性，見第5部分）。Xen方法使用一個單獨的VMM，這使最佳的（或最好的）處理變得困難，因為所有記憶體管理實現的複雜性，包括像發現記憶體範圍之類“瑣碎的”事情，必須被複制於VMM。OS有完全成熟的與最佳的實現；人們確實想避免複製它們。

圖 4.5: KVM 虛擬化模型

這就是為什麼對VMM/Dom0模型的分析是這麼有吸引力的一個選擇。圖4.5顯示了KVM的Linux核心擴充套件如何嘗試解決這個問題的。並沒有直接執行在硬體之上且管理所有客戶的單獨的VMM，替代的，一個普通的Linux核心接管了這個功能。這意味著Linux核心中完整且複雜的記憶體管理功能，被用來管理系統的記憶體。客戶域執行於普通的使用者級程式，建立者稱其為“客戶模式”。虛擬化的功能，引數的或全虛擬化的，被另一個使用者級程式KVM VMM控制。這也就是另一個程式用特別的核心實現的KVM裝置，去恰巧控制一個客戶域。

這個模型相較Xen獨立的VMM模型好處在於，即使客戶OS使用時，仍然有兩個記憶體處理程式在工作，只需要在Linux核心裡有一個實現。不需要像Xen VMM那樣從另一段程式碼複製同樣的功能。這帶來更少的工作，更少的bug，或許還有更少的兩個記憶體處理程式接觸產生的摩擦，因為一個Linux客戶的記憶體處理程式與執行於裸硬體之上的Linux核心的外部記憶體處理程式，做出了相同的假設。

總的來說，程式設計師必須清醒認識到，採用虛擬化時，記憶體操作的代價比沒有虛擬化要高很多。任何減少這個工作的優化，將在虛擬化環境付出更多。隨著時間的過去，處理器的設計者將通過像EPT和NPT技術越來越減少這個差距，但它永遠都不會完全消失。