級別： 初級
paul larson
), 軟體工程師, linux technology center, ibm
2004 年 4 月 01 日
隨著 linux 核心的發展和成熟，更多的使用者期待著 linux 可以執行非常大的系統來處理科學分析應用程式或者甚至海量資料庫。這些企業級的應用程式通常需要大量的記憶體才能好好執行。2.4 linux 核心有識別相當大數量的記憶體的功能，但是 2.5 核心發生了很多改變，使其有能力以更有效的方式處理更大量的記憶體。
反向對映
在 linux 記憶體管理器中，頁表保持對程序使用的記憶體物理頁的追蹤，它們將虛擬頁對映到物理頁。這些頁中有一些可能不是長時間使用，它們應該被交換出去。不過，在它們可以被交換出去之前，必須找到對映那個頁的每乙個程序，這樣那些程序中相應頁的頁表條目才可以被更新。在 linux 2.4 核心中，這是一項令人生畏的任務，因為為了確定某個頁是否被某個程序對映，必須遍歷每個程序的頁表。隨著在系統中執行的程序數量的增加，將這些頁交換出去的工作量也會增加。
反向對映，或者說是 rmap，就是為解決此問題而在 2.5 核心中實現的。反向對映提供了乙個發現哪些程序正在使用給定的記憶體物理頁的機制。不再是遍歷每個程序的頁表，記憶體管理器現在為每乙個物理頁建立了乙個鍊錶，包含了指向當前對映那個頁的每乙個程序的頁表條目（page-table entries, pte）的指標。這個鍊錶叫做 pte 鏈。pte 鏈極大地提高了找到那些對映某個頁的程序的速度，如圖 1 所示。
圖 1. 2.6 中的反向對映
反向對映還帶來了一些其他的複雜性。當頁被乙個程序對映時，必須為所有那些頁建立反向對映。同樣，當乙個程序釋放對頁的對映時，相應的對映也必須都刪除掉。這在退出時尤其常見。所有這些操作都必須在鎖定情況下進行。對那些執行很多派生和退出的應用程式來說，這可能會非常浪費並且增加很多開銷。
儘管有一些折衷，但可以證明反向對映是對 linux 記憶體管理器的乙個頗有價值的修改。通過這一途徑，查詢定位對映某個頁的程序這一嚴重瓶頸被最小化為只需要乙個簡單的操作。當大型應用程式向核心請求大量記憶體和多個程序共享記憶體時，反向對映幫助系統繼續有效地執行和擴充套件。當前還有更多對反向對映的改進正在研究中，可能會出現在未來的 linux 核心版本中。
大記憶體頁
典型地，記憶體管理器在 x86 系統上處理的記憶體頁為 4 kb。實際的頁大小是與體系結構相關的。對大部分用途來說，記憶體管理器以這樣大小的頁來管理記憶體是最有效的。不過，有一些應用程式要使用特別多的記憶體。大型資料庫就是其中乙個常見的例子。由於每個頁都要由每個程序對映，必須建立頁表條目來將虛擬位址對映到實體地址。如果您的乙個程序要使用 4kb 的頁來對映 1 gb 記憶體，這將用到 262,144 個頁表條目來保持對那些頁的追蹤。如果每個頁表條目消耗 8 個位元組，那些每對映 1 gb 記憶體需要 2 mb 的開銷。這本身就已經是非常可觀的開銷了，不過，如果有多個程序共享那些記憶體時，問題會變得更嚴重。在這種情況下，每個對映到同一塊 1 gb 記憶體的程序將為頁表條目付出自己 2 mb 的代價。如果有足夠多的程序，內存在開銷上的浪費可能會超過應用程式請求使用的記憶體數量。
解決這一問題的乙個方法是使用更大的頁。大部分新的處理器都支援至少乙個小的和乙個大的記憶體頁大小。在 x86 上，大記憶體頁的大小是 4 mb，或者，在實體地址擴充套件（pae）開啟的系統上是 2 mb。假定在前面的中使用頁大小為 4 mb 的大記憶體頁，同樣 1 gb 記憶體只用 256 個頁表條目就可以對映，而不需要 262,144 個。這樣開銷從 2 mb 變為 2,048 個位元組。
大記憶體頁的使用還可以通過減少 變換索引緩衝（translation lookaside buffer, tlb）的失敗次數來提高效能。tlb 是一種頁表的快取記憶體，讓那些在表中列出的頁可以更快地進行虛擬位址到實體地址的轉換。大記憶體頁可以用更少的實際頁來提供更多的記憶體，相當於較小的頁大小，使用的大記憶體頁越多，就有越多的記憶體可以通過 tlb 引用。
在高階記憶體中儲存頁表條目
在 32 位機器上頁表通常只可以儲存在低端記憶體中。低端記憶體只限於物理記憶體的前 896 mb，同時還要滿足核心其餘的大部分要求。在應用程式使用了大量程序並映**大量記憶體的情況下，低端記憶體可能很快就不夠用了。
現在，在 2.6 核心中有乙個配置選項叫做 highmem pte，讓頁表條目可以存放在高階記憶體中，釋放出更多的低端記憶體區域給那些必須放在這裡的其他核心資料結構。作為代價，使用這些頁表條目的程序會稍微慢一些。不過，對於那些在大量程序在執行的系統來說，將頁表儲存到高階記憶體中可以在低端記憶體區域擠出更多的記憶體。
圖 2. 記憶體區域
穩定性更好的穩定性是 2.6 記憶體管理器的另乙個重要改進。當 2.4 核心發布時，使用者幾乎馬上就開始遇到記憶體管理相關的穩定性問題。從記憶體管理對整個系統的影響來看，穩定性是至關重要的。問題大部分已經解決，但是解決方案必須從根本上推翻原來的記憶體管理器並重寫乙個簡單的多的管理器來取代它。這為 linux 的發行者改進自己特定發行版本的 linux 的記憶體管理器留下了很大的空間。不過，那些改進的另一方面是，在 2.4 中的記憶體管理部件由於使用的發行版本不同而很不相同。為避免再發生這樣的事情，記憶體管理成為 2.6 中核心開發的最細緻的一部分。從很低端的桌面系統到大型的、企業級的、多處理器的系統，新的記憶體管理**已經在它們上面都已經進行了測試和優化。
結束語linux 2.6 核心中記憶體管理的改進遠遠不只本文中提到的這些特性。很多變化是細微的，卻相當重要。這些變化一起促生了 2.6 核心中的記憶體管理器，它的設計目標是更高的效能、效率和穩定性。有一些變化，比如 highmem pte 和大記憶體頁，目的是減少記憶體管理帶來的開銷。其他變化，比如反向對映，提高了某些關鍵領域的效能。之所以選擇這些特別的例子，是因為它們舉例說明了 linux 2.6 核心得到了怎樣的調整和增強，以便更好地處理企業級的硬體和應用程式。
參考資料
關於作者
paul larson 為 ibm linux technology center 的 linux test 團隊工作。過去一年中，他從事的專案包括 linux 測試專案、2.5/2.6 核心穩定性以及核心**覆蓋分析。可以通過 [email protected]
與他聯絡。
核心比較 2 6 核心中改進了記憶體管理
從大記憶體頁到反向對映 更高的穩定性和更快的速度 paul larson pl us.ibm.com 軟體工程師,linux technology center,ibm 標記本文！建議 隨著 linux 核心的發展和成熟，更多的使用者期待著 linux 可以執行非常大的系統來處理科學分析應用程式或者...
核心比較 2 6 核心中改進了記憶體管理
隨著 linux 核心的發展和成熟，更多的使用者期待著 linux 可以執行非常大的系統來處理科學分析應用程式或者甚至海量資料庫。這些企業級的應用程式通常需要大量的記憶體才能好好執行。2.4 linux 核心有識別相當大數量的記憶體的功能，但是 2.5 核心發生了很多改變，使其有能力以更有效的方式處...
Linux2 6核心比2 4核心的改進細節
1.模組子系統 module subsystem 統一裝置模型 unified device model 和 pnp支援模組子系統發生了重大變化。文章 www.iocblog.net 2.穩定性有所提高 為了徹底避免核心載入或者匯出正在被使用的核心模組，或者至少為了減少載入或者解除安裝模組的同時使用...