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

[編輯註：本文是Ulrich Drepper的“每個程式員應該瞭解的記憶體方面的知識”文章的第三部分；這一部分談論了虛擬記憶體，特別是TLB效能。沒有閱讀第1部分和第2部分的人可能現在就想讀一讀了。和往常一樣，請將排字錯誤報表之類發送到lwn@lwn.net，而不要發送到這裡的評論。] 4 虛擬記憶體 處理器的虛擬記憶體子系統為每個進程實現了虛擬位址空間。這讓每個進程認為它在系統中是獨立的。虛擬記憶體的優點列表別的地方描述的非常詳細，所以這裡就不重複了。本節集中在虛擬記憶體的實際的實現細節，和相關的成本。

super0555 翻譯於 6天前 1人頂 頂 翻譯的不錯哦!

虛擬位址空間是由CPU的記憶體管理單元(MMU)實現的。OS必須填充頁表資料結構，但大多數CPU自己做了剩下的工作。這事實上是一個相當複雜的機制；最好的理解它的方法是引入資料結構來描述虛擬位址空間。 由MMU進行地址翻譯的輸入地址是虛擬位址。通常對它的值很少有限制 — 假設還有一點的話。 虛擬位址在32位系統中是32位的數值，在64位系統中是64位的數值。在一些系統，例如x86和x86-64，使用的地址實際上包含了另一個層次的間接定址：這些結構使用分段，這些分段只是簡單的給每個邏輯地址加上位移。我們可以忽略這一部分的地址產生，它不重要，不是程式員非常關心的記憶體處理效能方面的東西。{x86的分段限制是與效能相關的，但那是另一回事了}

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

4.1 最簡單的地址轉換 有趣的地方在於由虛擬位址到物理地址的轉換。MMU可以在逐頁的基礎上重新對應地址。就像地址緩衝排列的時候，虛擬位址被分割為不同的部分。這些部分被用來做多個表的索引，而這些表是被用來建立最終物理地址用的。最簡單的模型是只有一級表。 Figure 4.1: 1-Level Address Translation 圖 4.1 顯示了虛擬位址的不同部分是如何使用的。高位元組部分是用來選擇一個頁目錄的條目；那個目錄中的每個地址可以被OS分別設定。頁目錄條目決定了實體記憶體頁的地址；頁面中可以有不止一個條目指向同樣的物理地址。完整的記憶體物理地址是由頁目錄獲得的頁地址和虛擬位址低位元組部分合并起來決定的。頁目錄條目還包含一些附加的頁面資訊，如存取權限。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

頁目錄的資料結構儲存在記憶體中。OS必須分配連續的實體記憶體，並將這個位址範圍的基地址存入一個特殊的寄存器。然後虛擬位址的適當的位被用來作為頁目錄的索引，這個頁目錄事實上是目錄條目的列表。 作為一個具體的例子，這是 x86機器4MB分頁設計。虛擬位址的位移部分是22位大小，足以定位一個4M頁內的每一個位元組。虛擬位址中剩下的10位指定頁目錄中1024個條目的一個。每個條目包括一個10位的4M頁內的基地址，它與位移結合起來形成了一個完整的32位地址。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

4.2 多級頁表 4MB的頁不是規範，它們會浪費很多記憶體，因為OS需要執行的許多操作需要記憶體頁的隊列。對於4kB的頁（32位機器的規範，甚至通常是64位機器的規範），虛擬位址的位移部分只有12位大小。這留下了20位作為頁目錄的指標。具有220個條目的表是不實際的。即使每個條目只要4位元，這個表也要4MB大小。由於每個進程可能具有其唯一的頁目錄，因為這些頁目錄許多系統中實體記憶體被綁定起來。 解決辦法是用多級頁表。然後這些就能表示一個稀疏的大的頁目錄，目錄中一些實際不用的地區不需要分配記憶體。因此這種表示更緊湊，使它可能為記憶體中的很多進程使用頁表而並不太影響效能。.

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

今天最複雜的頁表結構由四級構成。圖4.2顯示了這樣一個實現的原理圖。 Figure 4.2: 4-Level Address Translation 在這個例子中，虛擬位址被至少分為五個部分。其中四個部分是不同的目錄的索引。被引用的第4級目錄使用CPU中一個特殊目的的寄存器。第4級到第2級目錄的內容是對次低一級目錄的引用。如果一個目錄條目標識為空白，顯然就是不需要指向任何低一級的目錄。這樣頁表樹就能稀疏和緊湊。正4.1，第1級目錄的條目是一部分物理地址，加上像存取權限的輔助資料。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

系統中啟動並執行每個進程可能需要自己的頁表樹。有部分共用樹的可能，但是這相當例外。因此如果頁表樹需要的記憶體儘可能小的話將對效能與可擴充性有利。理想的情況是將使用的記憶體緊靠著放在虛擬位址空間；但實際使用的物理地址不影響。一個小程式可能只需要第2，3，4級的一個目錄和少許第1級目錄就能應付過去。在一個採用4kB頁面和每個目錄512條目的x86-64機器上，這允許用4級目錄對2MB定位（每一級一個）。1GB連續的記憶體可以被第2到第4級的一個目錄和第1級的512個目錄定位。 但是，假設所有記憶體可以被連續分配是太簡單了。由於複雜的原因，大多數情況下，一個進程的棧與堆的地區是被分配在地址空間中非常相反的兩端。這樣使得任一個地區可以根據需要儘可能的增長。這意味著最有可能需要兩個第2級目錄和相應的更多的低一級的目錄。	super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!
	其它翻譯版本(1)

但即使這也不常常匹配現在的實際。由於安全的原因，一個可啟動並執行（代碼，資料，堆，棧，動態共用對象，aka共用庫）不同的部分被映射到隨機的地址[未選中的]。隨機化延伸到不同部分的相對位置；那意味著一個進程使用的不同的記憶體範圍，遍佈於虛擬位址空間。通過對隨機的地址位元採用一些限定，範圍可以被限制，但在大多數情況下，這當然不會讓一個進程只用一到兩個第2和第3級目錄運行。 如果效能真的遠比安全重要，隨機化可以被關閉。OS然後通常是在虛擬記憶體中至少連續的裝載所有的動態共用對象(DSO)。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

所以，替代於只是緩衝目錄表條目，物理頁地址的完整的計算結果被緩衝了。因為同樣的原因，代碼和資料緩衝也工作起來，這樣的地址計算結果的緩衝是高效的。由於虛擬位址的頁面位移部分在物理頁地址的計算中不起任何作用，只有虛擬位址的剩餘部分被用作緩衝的標籤。根據頁面大小這意味著成百上千的指令或資料對象共用同一個標籤，因此也共用同一個物理地址首碼。 儲存計算數值的緩衝叫做旁路轉換緩衝(TLB)。因為它必須非常的快，通常這是一個小的緩衝。現代CPU像其它緩衝一樣，提供了多級TLB緩衝；越進階的緩衝越大越慢。小號的L1級TLB通常被用來做全相聯映像緩衝，採用LRU回收策略。最近這種緩衝大小變大了，而且在處理器中變得集相聯。其結果之一就是，當一個新的條目必須被添加的時候，可能不是最久的條目被回收於替換了。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

正如上面提到的，用來訪問TLB的標籤是虛擬位址的一個部分。如果標籤在緩衝中有匹配，最終的物理地址將被計算出來，通過將來自虛擬位址的頁面位移地址加到緩衝值的方式。這是一個非常快的過程；也必須這樣，因為每條使用絕對位址的指令都需要物理地址，還有在一些情況下，因為使用物理地址作為關鍵字的L2尋找。如果TLB查詢未命中，處理器就必須執行一次頁表遍曆；這可能代價非常大。 通過軟體或硬體預取代碼或資料，會在地址位於另一頁面時，暗中預取TLB的條目。硬體預取不可能允許這樣，因為硬體會初始化非法的頁面表遍曆。因此程式員不能依賴硬體預取機制來預取TLB條目。它必須使用預取指令明確的完成。就像資料和指令緩衝，TLB可以表現為多個等級。正如資料緩衝，TLB通常表現為兩種形式：指令TLB(ITLB)和資料TLB(DTLB)。進階的TLB像L2TLB通常是統一的，就像其他的緩衝情形一樣。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

4.3.1 使用TLB的注意事項 TLB是以處理器為核心的全域資源。所有運行於處理器的線程與進程使用同一個TLB。由於虛擬到物理地址的轉換依賴於安裝的是哪一種頁表樹，如果頁表變化了，CPU不能盲目的重複使用緩衝的條目。每個進程有一個不同的頁表樹（不算在同一個進程中的線程），核心與記憶體管理器VMM(管理程式)也一樣，如果存在的話。也有可能一個進程的地址空間布局發生變化。有兩種解決這個問題的辦法： 當頁表樹變化時TLB重新整理。 TLB條目的標籤附加擴充並唯一標識其涉及的頁表樹 第一種情況，只要執行一個環境切換TLB就被重新整理。因為大多數OS中，從一個線程/進程到另一個的切換需要執行一些核心代碼，TLB重新整理被限制進入或離開核心地址空間。在虛擬化的系統中，當核心必須調用記憶體管理器VMM和返回的時候，這也會發生。如果核心和/或記憶體管理器沒有使用虛擬位址，或者當進程或核心調用系統/記憶體管理器時，能重複使用同一個虛擬位址，TLB必須被重新整理。當離開核心或記憶體管理器時，處理器繼續執行一個不同的進程或核心。

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

當然事實逃脫不了CPU的結構。對緩衝重新整理最佳化的一個可能的方法是單獨的使TLB條目失效。例如，如果核心代碼與資料落於一個特定的位址範圍，只有落入這個位址範圍的頁面必須被清除出TLB。這隻需要比較標籤，因此不是很昂貴。在部分地址空間改變的場合，例如對去除記憶體頁的一次調用，這個方法也是有用的， 更好的解決方案是為TLB訪問擴充標籤。如果除了虛擬位址的一部分之外，一個唯一的對應每個頁表樹的標識（如一個進程的地址空間）被添加，TLB將根本不需要完全重新整理。核心，記憶體管理程式，和獨立的進程都可以有唯一的標識。這種情境唯一的問題在於，TLB標籤可以獲得的位元異常有限，但是地址空間的位元卻不是。這意味著一些標識的再利用是有必要的。這種情況發生時TLB必須部分重新整理（如果可能的話）。所有帶有再利用標識的條目必須被重新整理，但是希望這是一個非常小的集合。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

當多個進程運行在系統中時，這種擴充的TLB標籤具有一般優勢。如果每個可運行進程對記憶體的使用（因此TLB條目的使用）做限制，進程最近使用的TLB條目,當其再次列入計劃時，有很大機會仍然在TLB。但還有兩個額外的優勢： 特殊的地址空間，像核心和記憶體管理器使用的那些，經常僅僅進入一小段時間；之後控制經常返回初始化此次調用的地址空間。沒有標籤，就有兩次TLB重新整理操作。有標籤，調用地址空間緩衝的轉換地址將被儲存，而且由於核心與記憶體管理器地址空間根本不會經常改變TLB條目，系統調用之前的地址轉換等等可以仍然使用。 當同一個進程的兩個線程之間切換時，TLB重新整理根本就不需要。雖然沒有擴充TLB標籤時，進入核心的條目會破壞第一個線程的TLB的條目。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

4.3.2 影響TLB效能 有一些因素會影響TLB效能。第一個是頁面的大小。顯然頁面越大，裝進去的指令或資料對象就越多。所以較大的頁面大小減少了所需的地址轉換總次數，即需要更少的TLB緩衝條目。大多數架構允許使用多個不同的頁面尺寸；一些尺寸可以並存使用。例如，x86/x86-64處理器有一個普通的4kB的頁面尺寸，但它們也可以分別用4MB和2MB頁面。IA-64 和 PowerPC允許如64kB的尺寸作為基本的頁面尺寸。 然而，大頁面尺寸的使用也隨之帶來了一些問題。用作大頁面的記憶體範圍必須是在實體記憶體中連續的。如果實體記憶體管理的單元大小升至虛擬記憶體頁面的大小，浪費的記憶體數量將會增長。各種記憶體操作（如載入可執行檔）需要頁面邊界對齊。這意味著平均每次映射浪費了實體記憶體中頁面大小的一半。這種浪費很容易累加；因此它給實體記憶體分配的合理單元大小劃定了一個上限。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

在x86-64結構中增加單元大小到2MB來適應大頁面當然是不實際的。這是一個太大的尺寸。但這轉而意味著每個大頁面必須由許多小一些的頁面組成。這些小頁面必須在實體記憶體中連續。以4kB單元頁面大小分配2MB連續的實體記憶體具有挑戰性。它需要找到有512個連續頁面的空閑地區。在系統運行一段時間並且實體記憶體開始片段化以後，這可能極為困難（或者不可能） 因此在Linux中有必要在系統啟動的時候，用特別的Huge TLBfs檔案系統，預分配這些大頁面。一個固定數目的物理頁面被保留，以單獨用作大的虛擬頁面。這使可能不會經常用到的資源捆綁留下來。它也是一個有限的池；增大它一般意味著要重啟系統。儘管如此，大頁面是進入某些局面的方法，在這些局面中效能具有保險性，資源豐富，而且麻煩的安裝不會成為大的妨礙。資料庫伺服器就是一個例子。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

增大最小的虛擬頁面大小（正如選擇大頁面的相反面）也有它的問題。記憶體映射操作（例如載入應用）必須確認這些頁面大小。不可能有更小的映射。對大多數架構來說，一個可執行程式的各個部分位置有一個固定的關係。如果頁面大小增加到超過了可執行程式或DSO(Dynamic Shared Object)建立時考慮的大小，載入操作將無法執行。腦海裡記得這個限制很重要。圖4.3顯示了一個ELF二進位的對齊需求是如何決定的。它編碼在ELF程式頭部。 $ eu-readelf -l /bin/lsProgram 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二進位，它的值為0x200000 = 2,097,152 = 2MB，符合處理器支援的最大頁面尺寸。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

使用較大記憶體尺寸有第二個影響：頁表樹的級數減少了。由於虛擬位址相對於頁面位移的部分增加了，需要用來在頁目錄中使用的位，就沒有剩下許多了。這意味著當一個TLB未命中時，需要做的工作數量減少了。 超出使用大頁面大小，它有可能減少移動資料時需要同時使用的TLB條目數目，減少到數頁。這與一些上面我們談論的緩衝使用的最佳化機制類似。只有現在對齊需求是巨大的。考慮到TLB條目數目如此小，這可能是一個重要的最佳化。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

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核心，然後就像他們是直接運行在一個處理器上一樣，實現通常的記憶體處理

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

為了實現完成虛擬化所需的各個域之間的分隔，Dom0和DomU核心中的記憶體處理不具有無限制的實體記憶體存取權限。VMM不是通過分發獨立的物理頁並讓客戶OS處理地址的方式來分發記憶體；這不能提供對錯誤或欺詐客戶域的防範。替代的，VMM為每一個客戶域建立它自己的頁表樹，並且用這些資料結構分發記憶體。好處是對頁表樹管理資訊的訪問能得到控制。如果代碼沒有合適的特權，它不能做任何事。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

在虛擬化的Xen支援中，這種存取控制已被開發，不管使用的是參數的或硬體的（又名全）虛擬化。客戶域以意圖上與參數的和硬體的虛擬化極為相似的方法，給每個進程建立它們的頁表樹。每當客戶OS修改了VMM調用的頁表，VMM就會用客戶域中更新的資訊去更新自己的影子頁表。這些是實際由硬體使用的頁表。顯然這個過程非常昂貴：每次對頁表樹的修改都需要VMM的一次調用。而沒有虛擬化時記憶體映射的改變也不便宜，它們現在變得甚至更昂貴。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

考慮到從客戶OS的變化到VMM以及返回，其本身已經相當昂貴，額外的代價可能真的很大。這就是為什麼處理器開始具有避免建立影子頁表的額外功能。這樣很好不僅是因為速度的問題，而且它減少了VMM消耗的記憶體。Intel有擴充頁表(EPTs)，AMD稱之為嵌套頁表(NPTs)。基本上兩種技術都具有客戶OS的頁表，來產生虛擬物理地址。然後通過每個域一個EPT/NPT樹的方式，這些地址會被進一步轉換為真實的物理地址。這使得可以用幾乎非虛擬化情境的速度進行記憶體處理，因為大多數用來記憶體處理的VMM條目被移走了。它也減少了VMM使用的記憶體，因為現在一個域（相對於進程）只有一個頁表樹需要維護。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

額外的地址轉換步驟的結果也儲存於TLB。那意味著TLB不儲存虛擬物理地址，而替代以完整的查詢結果。已經解釋過AMD的帕西菲卡擴充為了避免TLB重新整理而給每個條目引入ASID。ASID的位元在最初版本的處理器擴充中是一位；這正好足夠區分VMM和客戶OS。Intel有服務同一個目的的虛擬處理器ID(VPIDs)，它們只有更多位。但對每個客戶域VPID是固定的，因此它不能標記單獨的進程，也不能避免TLB在那個層級重新整理。

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

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

super0555 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

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

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

摘自：http://www.oschina.net/translate/what-every-programmer-should-know-about-virtual-memory-part3?from=20130324