linux vm balance 翻譯

沒有_GFP_WAIT和GFP_IO標誌的記憶體配置需要記憶體平衡。

這裡有兩個原因需要進行 non __GFP_WAIT的分配：1.調用者不能睡眠(特別是在中斷上下文中)。2.或者處於某些原因不想費時間在頁面分配或是swap io上。

__GFP_IO 標誌是為了防止檔案系統的死結。

如果缺乏無睡眠的記憶體配置請求，進行記憶體平衡看起來是有害的。頁面回收可以在需要(zone free memory is 0的時候)的時候進行，而不是主動的進行。

That being said, the kernel should try to fulfill requests for direct mapped pages from the direct mapped pool,

instead of falling back onthe dma pool, so as to keep the dma pool filled for dma requests (atomicor not).同樣方式也適合高端記憶體和直接映射頁面。如果有很多閒置dma頁面，直接從dma 記憶體池中分配就可以很好的滿足一般的分配請求，而不需要花費時間去進行zone 的記憶體平衡。

在2.2，記憶體平衡和頁面回收只有在空閑頁面率低於記憶體總量的1/64的時候才會被觸發。因為dma和普通記憶體的比例，很有可能在dma記憶體區完全空了也不會進行記憶體平衡。2.2通常跑在多記憶體的機器上，即時存在上面的問題，看起來工作的也不錯。在2.3，因為有了高端記憶體，問題更嚴重了。

在2.3,平衡zone可以採取兩種方式中的一種：取決於zone的大小(可能是lower class zone的大小)，我們可以在初始化的時候決定需要的空閑頁，以次為目標進行記憶體平衡。好的方面是我們不需要檢查lower class zones 的大小，不好的方面是我們忽略了lower class zones的使用率，所以需要經常進行平衡。Also,with a slight change in the allocation routine, it is possible to reduce the memclass() macro to be a simple equality.

另外一個解決方案是：當一個zone的空閑率和該zone的lower class zones 都 低於總記憶體的 1/64的時候才進行平衡。這解決了2.2的問題，同時給保持了和2.2同樣的處理行為。當然，平衡演算法在各種不同的結構體繫上是一樣的。如果我們想做的更好，將來可以給不同的zones賦予不同的權值。

注意到一點，如果普通zone遠遠大於dma zone,當進行普通zone的平衡的時候dma zone就幾乎去不了作用了。第一個解決方案可以處理的更好。