編輯注：本文是Ulrich Drepper的“每個程序員應(yīng)該了解的內(nèi)存方面的知識”文章的第三部分；這一部分談?wù)摿颂摂M內(nèi)存，特別是TLB性能。沒有閱讀第1部分和第2部分的人可能現(xiàn)在就想讀一讀了。和往常一樣，請將排字錯誤報告之類發(fā)送到lwn@lwn.net，而不要發(fā)送到這里的評論。

4 虛擬內(nèi)存

處理器的虛擬內(nèi)存子系統(tǒng)為每個進程實現(xiàn)了虛擬地址空間。這讓每個進程認(rèn)為它在系統(tǒng)中是獨立的。虛擬內(nèi)存的優(yōu)點列表別的地方描述的非常詳細(xì)，所以這里就不重復(fù)了。本節(jié)集中在虛擬內(nèi)存的實際的實現(xiàn)細(xì)節(jié)，和相關(guān)的成本。

虛擬地址空間是由CPU的內(nèi)存管理單元(MMU)實現(xiàn)的。OS必須填充頁表數(shù)據(jù)結(jié)構(gòu)，但大多數(shù)CPU自己做了剩下的工作。這事實上是一個相當(dāng)復(fù)雜的機制；***的理解它的方法是引入數(shù)據(jù)結(jié)構(gòu)來描述虛擬地址空間。

由MMU進行地址翻譯的輸入地址是虛擬地址。通常對它的值很少有限制 — 假設(shè)還有一點的話。 虛擬地址在32位系統(tǒng)中是32位的數(shù)值，在64位系統(tǒng)中是64位的數(shù)值。在一些系統(tǒng)，例如x86和x86-64，使用的地址實際上包含了另一個層次的間接尋址：這些結(jié)構(gòu)使用分段，這些分段只是簡單的給每個邏輯地址加上位移。我們可以忽略這一部分的地址產(chǎn)生，它不重要，不是程序員非常關(guān)心的內(nèi)存處理性能方面的東西。{x86的分段限制是與性能相關(guān)的，但那是另一回事了}

4.1 最簡單的地址轉(zhuǎn)換

有趣的地方在于由虛擬地址到物理地址的轉(zhuǎn)換。MMU可以在逐頁的基礎(chǔ)上重新映射地址。就像地址緩存排列的時候，虛擬地址被分割為不同的部分。這些部分被用來做多個表的索引，而這些表是被用來創(chuàng)建最終物理地址用的。最簡單的模型是只有一級表。

Figure 4.1: 1-Level Address Translation

圖 4.1 顯示了虛擬地址的不同部分是如何使用的。高字節(jié)部分是用來選擇一個頁目錄的條目；那個目錄中的每個地址可以被OS分別設(shè)置。頁目錄條目決定了物理內(nèi)存頁的地址；頁面中可以有不止一個條目指向同樣的物理地址。完整的內(nèi)存物理地址是由頁目錄獲得的頁地址和虛擬地址低字節(jié)部分合并起來決定的。頁目錄條目還包含一些附加的頁面信息，如訪問權(quán)限。

頁目錄的數(shù)據(jù)結(jié)構(gòu)存儲在內(nèi)存中。OS必須分配連續(xù)的物理內(nèi)存，并將這個地址范圍的基地址存入一個特殊的寄存器。然后虛擬地址的適當(dāng)?shù)奈槐挥脕碜鳛轫撃夸浀乃饕?，這個頁目錄事實上是目錄條目的列表。

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

4.2 多級頁表

4MB的頁不是規(guī)范，它們會浪費很多內(nèi)存，因為OS需要執(zhí)行的許多操作需要內(nèi)存頁的隊列。對于4kB的頁（32位機器的規(guī)范，甚至通常是64位機器的規(guī)范），虛擬地址的位移部分只有12位大小。這留下了20位作為頁目錄的指針。具有2²⁰個條目的表是不實際的。即使每個條目只要4比特，這個表也要4MB大小。由于每個進程可能具有其唯一的頁目錄，因為這些頁目錄許多系統(tǒng)中物理內(nèi)存被綁定起來。

解決辦法是用多級頁表。然后這些就能表示一個稀疏的大的頁目錄，目錄中一些實際不用的區(qū)域不需要分配內(nèi)存。因此這種表示更緊湊，使它可能為內(nèi)存中的很多進程使用頁表而并不太影響性能。.

今天最復(fù)雜的頁表結(jié)構(gòu)由四級構(gòu)成。圖4.2顯示了這樣一個實現(xiàn)的原理圖。

Figure 4.2: 4-Level Address Translation

在這個例子中，虛擬地址被至少分為五個部分。其中四個部分是不同的目錄的索引。被引用的第4級目錄使用CPU中一個特殊目的的寄存器。第4級到第2 級目錄的內(nèi)容是對次低一級目錄的引用。如果一個目錄條目標(biāo)識為空，顯然就是不需要指向任何低一級的目錄。這樣頁表樹就能稀疏和緊湊。正如圖4.1，第1級目錄的條目是一部分物理地址，加上像訪問權(quán)限的輔助數(shù)據(jù)。

為了決定相對于虛擬地址的物理地址，處理器先決定***級目錄的地址。這個地址一般保存在一個寄存器。然后CPU取出虛擬地址中相對于這個目錄的索引部分，并用那個索引選擇合適的條目。這個條目是下一級目錄的地址，它由虛擬地址的下一部分索引。處理器繼續(xù)直到它到達第1級目錄，那里那個目錄條目的值就是物理地址的高字節(jié)部分。物理地址在加上虛擬地址中的頁面位移之后就完整了。這個過程稱為頁面樹遍歷。一些處理器（像x86和x86-64）在硬件中執(zhí)行這個操作，其他的需要OS的協(xié)助。

系統(tǒng)中運行的每個進程可能需要自己的頁表樹。有部分共享樹的可能，但是這相當(dāng)例外。因此如果頁表樹需要的內(nèi)存盡可能小的話將對性能與可擴展性有利。理想的情況是將使用的內(nèi)存緊靠著放在虛擬地址空間；但實際使用的物理地址不影響。一個小程序可能只需要第2，3，4級的一個目錄和少許第1級目錄就能應(yīng)付過去。在一個采用4kB頁面和每個目錄512條目的x86-64機器上，這允許用4級目錄對2MB定位（每一級一個）。1GB連續(xù)的內(nèi)存可以被第2到第4 級的一個目錄和第1級的512個目錄定位。

但是，假設(shè)所有內(nèi)存可以被連續(xù)分配是太簡單了。由于復(fù)雜的原因，大多數(shù)情況下，一個進程的棧與堆的區(qū)域是被分配在地址空間中非常相反的兩端。這樣使得任一個區(qū)域可以根據(jù)需要盡可能的增長。這意味著最有可能需要兩個第2級目錄和相應(yīng)的更多的低一級的目錄。

但即使這也不常常匹配現(xiàn)在的實際。由于安全的原因，一個可運行的（代碼，數(shù)據(jù)，堆，棧，動態(tài)共享對象，aka共享庫）不同的部分被映射到隨機的地址 [未選中的]。隨機化延伸到不同部分的相對位置；那意味著一個進程使用的不同的內(nèi)存范圍，遍布于虛擬地址空間。通過對隨機的地址位數(shù)采用一些限定，范圍可以被限制，但在大多數(shù)情況下，這當(dāng)然不會讓一個進程只用一到兩個第2和第3級目錄運行。

如果性能真的遠比安全重要，隨機化可以被關(guān)閉。OS然后通常是在虛擬內(nèi)存中至少連續(xù)的裝載所有的動態(tài)共享對象(DSO)。

4.3 優(yōu)化頁表訪問

頁表的所有數(shù)據(jù)結(jié)構(gòu)都保存在主存中；在那里OS建造和更新這些表。當(dāng)一個進程創(chuàng)建或者一個頁表變化，CPU將被通知。頁表被用來解決每個虛擬地址到物理地址的轉(zhuǎn)換，用上面描述的頁表遍歷方式。更多有關(guān)于此：至少每一級有一個目錄被用于處理虛擬地址的過程。這需要至多四次內(nèi)存訪問（對一個運行中的進程的單次訪問來說），這很慢。有可能像普通數(shù)據(jù)一樣處理這些目錄表條目，并將他們緩存在L1d,L2等等，但這仍然非常慢。

從虛擬內(nèi)存的早期階段開始，CPU的設(shè)計者采用了一種不同的優(yōu)化。簡單的計算顯示，只有將目錄表條目保存在L1d和更高級的緩存，才會導(dǎo)致可怕的性能問題。每個絕對地址的計算，都需要相對于頁表深度的大量的L1d訪問。這些訪問不能并行，因為它們依賴于前面查詢的結(jié)果。在一個四級頁表的機器上，這種單線性將 至少至少需要12次循環(huán)。再加上L1d的非命中的可能性，結(jié)果是指令流水線沒有什么能隱藏的。額外的L1d訪問也消耗了珍貴的緩存帶寬。

所以，替代于只是緩存目錄表條目，物理頁地址的完整的計算結(jié)果被緩存了。因為同樣的原因，代碼和數(shù)據(jù)緩存也工作起來，這樣的地址計算結(jié)果的緩存是高效的。由于虛擬地址的頁面位移部分在物理頁地址的計算中不起任何作用，只有虛擬地址的剩余部分被用作緩存的標(biāo)簽。根據(jù)頁面大小這意味著成百上千的指令或數(shù)據(jù)對象共享同一個標(biāo)簽，因此也共享同一個物理地址前綴。

保存計算數(shù)值的緩存叫做旁路轉(zhuǎn)換緩存(TLB)。因為它必須非常的快，通常這是一個小的緩存?，F(xiàn)代CPU像其它緩存一樣，提供了多級TLB緩存；越高級的緩存越大越慢。小號的L1級TLB通常被用來做全相聯(lián)映像緩存，采用LRU回收策略。最近這種緩存大小變大了，而且在處理器中變得集相聯(lián)。其結(jié)果之一就是，當(dāng)一個新的條目必須被添加的時候，可能不是最久的條目被回收于替換了。

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

通過軟件或硬件預(yù)取代碼或數(shù)據(jù)，會在地址位于另一頁面時，暗中預(yù)取TLB的條目。硬件預(yù)取不可能允許這樣，因為硬件會初始化非法的頁面表遍歷。因此程序員不能依賴硬件預(yù)取機制來預(yù)取TLB條目。它必須使用預(yù)取指令明確的完成。就像數(shù)據(jù)和指令緩存，TLB可以表現(xiàn)為多個等級。正如數(shù)據(jù)緩存，TLB通常表現(xiàn)為兩種形式：指令TLB(ITLB)和數(shù)據(jù)TLB(DTLB)。高級的TLB像L2TLB通常是統(tǒng)一的，就像其他的緩存情形一樣。

#p#

4.3.1 使用TLB的注意事項

TLB是以處理器為核心的全局資源。所有運行于處理器的線程與進程使用同一個TLB。由于虛擬到物理地址的轉(zhuǎn)換依賴于安裝的是哪一種頁表樹，如果頁表變化了，CPU不能盲目的重復(fù)使用緩存的條目。每個進程有一個不同的頁表樹（不算在同一個進程中的線程），內(nèi)核與內(nèi)存管理器VMM(管理程序)也一樣，如果存在的話。也有可能一個進程的地址空間布局發(fā)生變化。有兩種解決這個問題的辦法：

• 當(dāng)頁表樹變化時TLB刷新。
• TLB條目的標(biāo)簽附加擴展并唯一標(biāo)識其涉及的頁表樹

***種情況，只要執(zhí)行一個上下文切換TLB就被刷新。因為大多數(shù)OS中，從一個線程/進程到另一個的切換需要執(zhí)行一些核心代碼，TLB刷新被限制進入或離開核心地址空間。在虛擬化的系統(tǒng)中，當(dāng)內(nèi)核必須調(diào)用內(nèi)存管理器VMM和返回的時候，這也會發(fā)生。如果內(nèi)核和/或內(nèi)存管理器沒有使用虛擬地址，或者當(dāng)進程或內(nèi)核調(diào)用系統(tǒng)/內(nèi)存管理器時，能重復(fù)使用同一個虛擬地址，TLB必須被刷新。當(dāng)離開內(nèi)核或內(nèi)存管理器時，處理器繼續(xù)執(zhí)行一個不同的進程或內(nèi)核。

刷新TLB高效但昂貴。例如，當(dāng)執(zhí)行一個系統(tǒng)調(diào)用，觸及的內(nèi)核代碼可能僅限于幾千條指令，或許少許新頁面（或一個大的頁面，像某些結(jié)構(gòu)的Linux 的就是這樣）。這個工作將替換觸及頁面的所有TLB條目。對Intel帶128ITLB和256DTLB條目的Core2架構(gòu)，完全的刷新意味著多于 100和200條目（分別的）將被不必要的刷新。當(dāng)系統(tǒng)調(diào)用返回同一個進程，所有那些被刷新的TLB條目可能被再次用到，但它們沒有了。內(nèi)核或內(nèi)存管理器常用的代碼也一樣。每條進入內(nèi)核的條目上，TLB必須擦去再裝，即使內(nèi)核與內(nèi)存管理器的頁表通常不會改變。因此理論上說，TLB條目可以被保持一個很長時間。這也解釋了為什么現(xiàn)在處理器中的TLB緩存都不大：程序很有可能不會執(zhí)行時間長到裝滿所有這些條目。

當(dāng)然事實逃脫不了CPU的結(jié)構(gòu)。對緩存刷新優(yōu)化的一個可能的方法是單獨的使TLB條目失效。例如，如果內(nèi)核代碼與數(shù)據(jù)落于一個特定的地址范圍，只有落入這個地址范圍的頁面必須被清除出TLB。這只需要比較標(biāo)簽，因此不是很昂貴。在部分地址空間改變的場合，例如對去除內(nèi)存頁的一次調(diào)用，這個方法也是有用的，

更好的解決方法是為TLB訪問擴展標(biāo)簽。如果除了虛擬地址的一部分之外，一個唯一的對應(yīng)每個頁表樹的標(biāo)識（如一個進程的地址空間）被添加，TLB將根本不需要完全刷新。內(nèi)核，內(nèi)存管理程序，和獨立的進程都可以有唯一的標(biāo)識。這種場景唯一的問題在于，TLB標(biāo)簽可以獲得的位數(shù)異常有限，但是地址空間的位數(shù)卻不是。這意味著一些標(biāo)識的再利用是有必要的。這種情況發(fā)生時TLB必須部分刷新（如果可能的話）。所有帶有再利用標(biāo)識的條目必須被刷新，但是希望這是一個非常小的集合。

當(dāng)多個進程運行在系統(tǒng)中時，這種擴展的TLB標(biāo)簽具有一般優(yōu)勢。如果每個可運行進程對內(nèi)存的使用（因此TLB條目的使用）做限制，進程最近使用的TLB條目,當(dāng)其再次列入計劃時，有很大機會仍然在TLB。但還有兩個額外的優(yōu)勢：

1. 特殊的地址空間，像內(nèi)核和內(nèi)存管理器使用的那些，經(jīng)常僅僅進入一小段時間；之后控制經(jīng)常返回初始化此次調(diào)用的地址空間。沒有標(biāo)簽，就有兩次TLB 刷新操作。有標(biāo)簽，調(diào)用地址空間緩存的轉(zhuǎn)換地址將被保存，而且由于內(nèi)核與內(nèi)存管理器地址空間根本不會經(jīng)常改變TLB條目，系統(tǒng)調(diào)用之前的地址轉(zhuǎn)換等等可以仍然使用。
2. 當(dāng)同一個進程的兩個線程之間切換時，TLB刷新根本就不需要。雖然沒有擴展TLB標(biāo)簽時，進入內(nèi)核的條目會破壞***個線程的TLB的條目。

有些處理器在一些時候?qū)崿F(xiàn)了這些擴展標(biāo)簽。AMD給帕西菲卡（Pacifica）虛擬化擴展引入了一個1位的擴展標(biāo)簽。在虛擬化的上下文中，這個1 位的地址空間ID（ASID）被用來從客戶域區(qū)別出內(nèi)存管理程序的地址空間。這使得OS能夠避免在每次進入內(nèi)存管理程序的時候（例如為了處理一個頁面錯誤）刷新客戶的TLB條目，或者當(dāng)控制回到客戶時刷新內(nèi)存管理程序的TLB條目。這個架構(gòu)未來會允許使用更多的位。其它主流處理器很可能會隨之適應(yīng)并支持這個功能。

4.3.2 影響TLB性能

有一些因素會影響TLB性能。***個是頁面的大小。顯然頁面越大，裝進去的指令或數(shù)據(jù)對象就越多。所以較大的頁面大小減少了所需的地址轉(zhuǎn)換總次數(shù)，即需要更少的TLB緩存條目。大多數(shù)架構(gòu)允許使用多個不同的頁面尺寸；一些尺寸可以并存使用。例如，x86/x86-64處理器有一個普通的4kB的頁面尺寸，但它們也可以分別用4MB和2MB頁面。IA-64 和 PowerPC允許如64kB的尺寸作為基本的頁面尺寸。

然而，大頁面尺寸的使用也隨之帶來了一些問題。用作大頁面的內(nèi)存范圍必須是在物理內(nèi)存中連續(xù)的。如果物理內(nèi)存管理的單元大小升至虛擬內(nèi)存頁面的大小，浪費的內(nèi)存數(shù)量將會增長。各種內(nèi)存操作（如加載可執(zhí)行文件）需要頁面邊界對齊。這意味著平均每次映射浪費了物理內(nèi)存中頁面大小的一半。這種浪費很容易累加；因此它給物理內(nèi)存分配的合理單元大小劃定了一個上限。

在x86-64結(jié)構(gòu)中增加單元大小到2MB來適應(yīng)大頁面當(dāng)然是不實際的。這是一個太大的尺寸。但這轉(zhuǎn)而意味著每個大頁面必須由許多小一些的頁面組成。這些小頁面必須在物理內(nèi)存中連續(xù)。以4kB單元頁面大小分配2MB連續(xù)的物理內(nèi)存具有挑戰(zhàn)性。它需要找到有512個連續(xù)頁面的空閑區(qū)域。在系統(tǒng)運行一段時間并且物理內(nèi)存開始碎片化以后，這可能極為困難（或者不可能）

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

增大最小的虛擬頁面大?。ㄕ邕x擇大頁面的相反面）也有它的問題。內(nèi)存映射操作（例如加載應(yīng)用）必須確認(rèn)這些頁面大小。不可能有更小的映射。對大多數(shù)架構(gòu)來說，一個可執(zhí)行程序的各個部分位置有一個固定的關(guān)系。如果頁面大小增加到超過了可執(zhí)行程序或DSO(Dynamic Shared Object)創(chuàng)建時考慮的大小，加載操作將無法執(zhí)行。腦海里記得這個限制很重要。圖4.3顯示了一個ELF二進制的對齊需求是如何決定的。它編碼在 ELF程序頭部。

$ eu-readelf -l /bin/ls  
Program Headers:  
  Type   Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align  
...  
  LOAD   0x000000 0x0000000000400000 0x0000000000400000 0x0132ac 0x0132ac R E 0x200000  
  LOAD   0x0132b0 0x00000000006132b0 0x00000000006132b0 0x001a71 0x001a71 RW  0x200000  
... 

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

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

使用較大內(nèi)存尺寸有第二個影響：頁表樹的級數(shù)減少了。由于虛擬地址相對于頁面位移的部分增加了，需要用來在頁目錄中使用的位，就沒有剩下許多了。這意味著當(dāng)一個TLB未命中時，需要做的工作數(shù)量減少了。

超出使用大頁面大小，它有可能減少移動數(shù)據(jù)時需要同時使用的TLB條目數(shù)目，減少到數(shù)頁。這與一些上面我們談?wù)摰木彺媸褂玫膬?yōu)化機制類似。只有現(xiàn)在對齊需求是巨大的。考慮到TLB條目數(shù)目如此小，這可能是一個重要的優(yōu)化。

4.4 虛擬化的影響

OS映像的虛擬化將變得越來越流行；這意味著另一個層次的內(nèi)存處理被加入了想象。進程（基本的隔間）或者OS容器的虛擬化，因為只涉及一個OS而沒有落入此分類。類似Xen或KVM的技術(shù)使OS映像能夠獨立運行 — 有或者沒有處理器的協(xié)助。這些情形下，有一個單獨的軟件直接控制物理內(nèi)存的訪問。

圖 4.4: Xen 虛擬化模型

對Xen來說（見圖4.4），Xen VMM(Xen內(nèi)存管理程序)就是那個軟件。但是，VMM沒有自己實現(xiàn)許多硬件的控制，不像其他早先的系統(tǒng)（包括Xen VMM的***個版本）的VMM，內(nèi)存以外的硬件和處理器由享有特權(quán)的Dom0域控制?，F(xiàn)在，這基本上與沒有特權(quán)的DomU內(nèi)核一樣，就內(nèi)存處理方面而言，它們沒有什么不同。這里重要的是，VMM自己分發(fā)物理內(nèi)存給Dom0和DomU內(nèi)核，然后就像他們是直接運行在一個處理器上一樣，實現(xiàn)通常的內(nèi)存處理

為了實現(xiàn)完成虛擬化所需的各個域之間的分隔，Dom0和DomU內(nèi)核中的內(nèi)存處理不具有無限制的物理內(nèi)存訪問權(quán)限。VMM不是通過分發(fā)獨立的物理頁并讓客戶OS處理地址的方式來分發(fā)內(nèi)存；這不能提供對錯誤或欺詐客戶域的防范。替代的，VMM為每一個客戶域創(chuàng)建它自己的頁表樹，并且用這些數(shù)據(jù)結(jié)構(gòu)分發(fā)內(nèi)存。好處是對頁表樹管理信息的訪問能得到控制。如果代碼沒有合適的特權(quán)，它不能做任何事。 在虛擬化的Xen支持中，這種訪問控制已被開發(fā)，不管使用的是參數(shù)的或硬件的（又名全）虛擬化?？蛻粲蛞砸鈭D上與參數(shù)的和硬件的虛擬化極為相似的方法，給每個進程創(chuàng)建它們的頁表樹。每當(dāng)客戶OS修改了VMM調(diào)用的頁表，VMM就會用客戶域中更新的信息去更新自己的影子頁表。這些是實際由硬件使用的頁表。顯然這個過程非常昂貴：每次對頁表樹的修改都需要VMM的一次調(diào)用。而沒有虛擬化時內(nèi)存映射的改變也不便宜，它們現(xiàn)在變得甚至更昂貴。 考慮到從客戶OS的變化到VMM以及返回，其本身已經(jīng)相當(dāng)昂貴，額外的代價可能真的很大。這就是為什么處理器開始具有避免創(chuàng)建影子頁表的額外功能。這樣很好不僅是因為速度的問題，而且它減少了VMM消耗的內(nèi)存。Intel有擴展頁表(EPTs)，AMD稱之為嵌套頁表(NPTs)?；旧蟽煞N技術(shù)都具有客戶OS的頁表，來產(chǎn)生虛擬的物理地址。然后通過每個域一個EPT/NPT樹的方式，這些地址會被進一步轉(zhuǎn)換為真實的物理地址。這使得可以用幾乎非虛擬化情境的速度進行內(nèi)存處理，因為大多數(shù)用來內(nèi)存處理的VMM條目被移走了。它也減少了VMM使用的內(nèi)存，因為現(xiàn)在一個域（相對于進程）只有一個頁表樹需要維護。 額外的地址轉(zhuǎn)換步驟的結(jié)果也存儲于TLB。那意味著TLB不存儲虛擬物理地址，而替代以完整的查詢結(jié)果。已經(jīng)解釋過AMD的帕西菲卡擴展為了避免TLB刷新而給每個條目引入ASID。ASID的位數(shù)在最初版本的處理器擴展中是一位；這正好足夠區(qū)分VMM和客戶OS。Intel有服務(wù)同一個目的的虛擬處理器 ID(VPIDs)，它們只有更多位。但對每個客戶域VPID是固定的，因此它不能標(biāo)記單獨的進程，也不能避免TLB在那個級別刷新。

對虛擬OS，每個地址空間的修改需要的工作量是一個問題。但是還有另一個內(nèi)在的基于VMM虛擬化的問題：沒有什么辦法處理兩層的內(nèi)存。但內(nèi)存處理很難（特別是考慮到像NUMA一樣的復(fù)雜性，見第5部分）。Xen方法使用一個單獨的VMM，這使***的（或***的）處理變得困難，因為所有內(nèi)存管理實現(xiàn)的復(fù)雜性，包括像發(fā)現(xiàn)內(nèi)存范圍之類“瑣碎的”事情，必須被復(fù)制于VMM。OS有完全成熟的與***的實現(xiàn)；人們確實想避免復(fù)制它們。

圖 4.5: KVM 虛擬化模型

這就是為什么對VMM/Dom0模型的分析是這么有吸引力的一個選擇。圖4.5顯示了KVM的Linux內(nèi)核擴展如何嘗試解決這個問題的。并沒有直接運行在硬件之上且管理所有客戶的單獨的VMM，替代的，一個普通的Linux內(nèi)核接管了這個功能。這意味著Linux內(nèi)核中完整且復(fù)雜的內(nèi)存管理功能，被用來管理系統(tǒng)的內(nèi)存。客戶域運行于普通的用戶級進程，創(chuàng)建者稱其為“客戶模式”。虛擬化的功能，參數(shù)的或全虛擬化的，被另一個用戶級進程KVM VMM控制。這也就是另一個進程用特別的內(nèi)核實現(xiàn)的KVM設(shè)備，去恰巧控制一個客戶域。

這個模型相較Xen獨立的VMM模型好處在于，即使客戶OS使用時，仍然有兩個內(nèi)存處理程序在工作，只需要在Linux內(nèi)核里有一個實現(xiàn)。不需要像 Xen VMM那樣從另一段代碼復(fù)制同樣的功能。這帶來更少的工作，更少的bug，或許還有更少的兩個內(nèi)存處理程序接觸產(chǎn)生的摩擦，因為一個Linux客戶的內(nèi)存處理程序與運行于裸硬件之上的Linux內(nèi)核的外部內(nèi)存處理程序，做出了相同的假設(shè)。

總的來說，程序員必須清醒認(rèn)識到，采用虛擬化時，內(nèi)存操作的代價比沒有虛擬化要高很多。任何減少這個工作的優(yōu)化，將在虛擬化環(huán)境付出更多。隨著時間的過去，處理器的設(shè)計者將通過像EPT和NPT技術(shù)越來越減少這個差距，但它永遠都不會完全消失。

英文原文：Memory part 3: Virtual Memory

譯文鏈接：http://www.oschina.net/translate/what-every-programmer-should-know-about-virtual-memory-part3