原文日期：2004/03/10
原文作者：Jonathan Corbet
原文連結：http://lwn.net/Articles/75174/
這篇文章主要是要提供一些背景知識，解釋為何在這次的開發周期中，核心開發者正在考慮從基本架構上修改虛擬記憶體的運作方式。已經了解high與low記憶體是如何在32位元系統上運作的讀者，可以略過這些說明。
一個32位元的處理器最多僅能定址4GB的記憶體。理論上，我們可以擴展指令集來允許更大的定址，但實際上沒有人這麼作，因為對於效能與可計算性的影響都太重了。所以限制依然存在：在32位元的系統上，沒有一個process可以有超過4GB的address space，核心也無法直接定址多過4GB的位址。
事實上，限制條件其實更加嚴重。Linux核心將4GB的address space分割為兩部份，在一般的設定上，32位元的前3GB分配給user space，核心則分配到從0xc0000000開始的1GB空間。共享address space有效能上的好處，硬體的address translation buffer可以被核心與user space共享。
如果核心想要直接存取系統的physical記憶體，必須先建立page table去對應進核心的address space。對於預設的3GB/1GB分割方式，可以直接定址的pyhsical記憶體就只有略小於1GB的數量 - 因為部份的核心空間必須放置核心本身、使用vmalloc()要到的記憶體以及很多其他用途。這也就是為何一直到幾年前(譯註：注意原文發佈時間在2004)，Linux都還不能完整使用32位元系統上超過1GB的記憶體。實際上，在1999年時，Linus甚至決定32位元的Linux不會支援超過2GB的記憶體。還嗆聲："這件事沒得談。"
Linus的想法沒有改變，但世界持續對於32位元必須支援更大量記憶體有所需求。處理器供應商還增加了新的paging modes，可以讓physical addresses超過32位元的範圍，因此使得4GB的限制消失了。然而，Linux核心對於定址的限制依然沒有改變。令大型系統使用者欣慰的是，Linus承認錯誤，並改變了心意，他最終允許在2.3的核心有更大的記憶體支援。然而，這項支援有著先天上的代價與限制。
在32位元系統上，記憶體被區分為high memory與low memory。Low memory還是直接對應進核心的address space，所以總是可以直接以核心空間的指標去存取。High memory則沒有直接的對應，使用前必須先明確地建立page table去完成對應進核心空間的動作。這個動作的代價可能會很昂貴，而且能夠同時對應進核心空間的high-memory pages也有數量上的限制。
核心本身的資料結構必須存在於low memory中。無法永久對應的記憶體不能給linked lists使用(因為其virtual address是暫時的、可變的)，而且對應與解除對應核心記憶體的效能代價太過高昂。High memory對於process pages與一些核心工作頗適合(舉例來說，I/O buffers)，但對於核心本身來說，必須存在low memory才行。
某些32位元處理器已經可以定址64GB的實體記憶體了，但Linux核心還無法有效地處理這麼大量的記憶體，目前的上限依據負載情況，大概可達到8GB~16GB。現在的問題在於更大的系統輕易地就將low memory使用殆盡。當系統愈來愈龐大，就會需要更多的核心資料結構來管理，最終要配給這些結構的空間就會用光。在非常大型的系統上，光是system memory map(一個struct page的陣列，表示實際的實體記憶體)就可以佔掉low memory的一半容量。
有些使用者想要將32位元的Linux系統擴展到32GB或更多記憶體，所以一些企業導向的Linux套件已經讓這件事變得可能了。一種作法是利用Ingo Molnar的4G/4G補丁。這個補丁將kernel address space與user address space分開來，允許user processes使用4GB的虛擬記憶體，同時擴展核心的low memory達到4GB。然而，這種作法需要付出代價：translation buffer不再被共享了，必須在每次的kernel/user space切換時進行清除動作。效能損失依據使用情況有很大的差別，不過30%的差距已被提出。即便如此，這樣的選項可以讓一些系統使用，Red Hat針對企業級應用提供了4G/4G的核心。
4G/4G補丁可擴展Linux核心的能力，但仍然不是很廣為使用。它被認為是一個醜陋的解法，沒有人願意效能變差。所以也存在其他的方式來擴展Linux核心。這些努力中的一部份很有可能會在2.6核心中看到，但核心開發者似乎很不情願讓核心中的記憶體管理變得這麼畸形，只是為了滿足少部份使用者想擴展32位元系統的期待。這時就差不多可以用1999年時Linus的答案去反擊了：去弄個64位元的系統。
原文作者：Jonathan Corbet
原文連結：http://lwn.net/Articles/75174/
這篇文章主要是要提供一些背景知識，解釋為何在這次的開發周期中，核心開發者正在考慮從基本架構上修改虛擬記憶體的運作方式。已經了解high與low記憶體是如何在32位元系統上運作的讀者，可以略過這些說明。
一個32位元的處理器最多僅能定址4GB的記憶體。理論上，我們可以擴展指令集來允許更大的定址，但實際上沒有人這麼作，因為對於效能與可計算性的影響都太重了。所以限制依然存在：在32位元的系統上，沒有一個process可以有超過4GB的address space，核心也無法直接定址多過4GB的位址。
事實上，限制條件其實更加嚴重。Linux核心將4GB的address space分割為兩部份，在一般的設定上，32位元的前3GB分配給user space，核心則分配到從0xc0000000開始的1GB空間。共享address space有效能上的好處，硬體的address translation buffer可以被核心與user space共享。
如果核心想要直接存取系統的physical記憶體，必須先建立page table去對應進核心的address space。對於預設的3GB/1GB分割方式，可以直接定址的pyhsical記憶體就只有略小於1GB的數量 - 因為部份的核心空間必須放置核心本身、使用vmalloc()要到的記憶體以及很多其他用途。這也就是為何一直到幾年前(譯註：注意原文發佈時間在2004)，Linux都還不能完整使用32位元系統上超過1GB的記憶體。實際上，在1999年時，Linus甚至決定32位元的Linux不會支援超過2GB的記憶體。還嗆聲："這件事沒得談。"
Linus的想法沒有改變，但世界持續對於32位元必須支援更大量記憶體有所需求。處理器供應商還增加了新的paging modes，可以讓physical addresses超過32位元的範圍，因此使得4GB的限制消失了。然而，Linux核心對於定址的限制依然沒有改變。令大型系統使用者欣慰的是，Linus承認錯誤，並改變了心意，他最終允許在2.3的核心有更大的記憶體支援。然而，這項支援有著先天上的代價與限制。
在32位元系統上，記憶體被區分為high memory與low memory。Low memory還是直接對應進核心的address space，所以總是可以直接以核心空間的指標去存取。High memory則沒有直接的對應，使用前必須先明確地建立page table去完成對應進核心空間的動作。這個動作的代價可能會很昂貴，而且能夠同時對應進核心空間的high-memory pages也有數量上的限制。
核心本身的資料結構必須存在於low memory中。無法永久對應的記憶體不能給linked lists使用(因為其virtual address是暫時的、可變的)，而且對應與解除對應核心記憶體的效能代價太過高昂。High memory對於process pages與一些核心工作頗適合(舉例來說，I/O buffers)，但對於核心本身來說，必須存在low memory才行。
某些32位元處理器已經可以定址64GB的實體記憶體了，但Linux核心還無法有效地處理這麼大量的記憶體，目前的上限依據負載情況，大概可達到8GB~16GB。現在的問題在於更大的系統輕易地就將low memory使用殆盡。當系統愈來愈龐大，就會需要更多的核心資料結構來管理，最終要配給這些結構的空間就會用光。在非常大型的系統上，光是system memory map(一個struct page的陣列，表示實際的實體記憶體)就可以佔掉low memory的一半容量。
有些使用者想要將32位元的Linux系統擴展到32GB或更多記憶體，所以一些企業導向的Linux套件已經讓這件事變得可能了。一種作法是利用Ingo Molnar的4G/4G補丁。這個補丁將kernel address space與user address space分開來，允許user processes使用4GB的虛擬記憶體，同時擴展核心的low memory達到4GB。然而，這種作法需要付出代價：translation buffer不再被共享了，必須在每次的kernel/user space切換時進行清除動作。效能損失依據使用情況有很大的差別，不過30%的差距已被提出。即便如此，這樣的選項可以讓一些系統使用，Red Hat針對企業級應用提供了4G/4G的核心。
4G/4G補丁可擴展Linux核心的能力，但仍然不是很廣為使用。它被認為是一個醜陋的解法，沒有人願意效能變差。所以也存在其他的方式來擴展Linux核心。這些努力中的一部份很有可能會在2.6核心中看到，但核心開發者似乎很不情願讓核心中的記憶體管理變得這麼畸形，只是為了滿足少部份使用者想擴展32位元系統的期待。這時就差不多可以用1999年時Linus的答案去反擊了：去弄個64位元的系統。
留言
張貼留言