本博客已經遷移至：本文將分析是否Huge Page在任何條件下（特別是NUMA架構下）都能帶來性能提升。
http://cenalulu.github.io/
為了更好的體驗，請通過此鏈接閱讀：http://cenalulu.github.io/linux/huge-page-on-numa/
文章歡迎轉載，但轉載時請保留本段文字，并置于文章的頂部作者：盧鈞軼(cenalulu)本文原文地址：http://cenalulu.github.io/linux/huge-page-on-numa/
在閱讀本文之前，需要讀者至少了解以下基礎知識
Chip Multi PRocessing aware Linux Kernel Scheduler論文在正式開始本文分析前，我們先大概介紹下Huge Page的歷史背景和使用場景。
為什么需要Huge Page了解CPU Cache大致架構的話，一定聽過TLB Cache。Linux系統中，對程序可見的，可使用的內存地址是Virtual Address。每個程序的內存地址都是從0開始的。而實際的數據訪問是要通過Physical Address進行的。因此，每次內存操作，CPU都需要從page table中把Virtual Address翻譯成對應的Physical Address，那么對于大量內存密集型程序來說page table的查找就會成為程序的瓶頸。所以現代CPU中就出現了TLB(Translation Lookaside Buffer) Cache用于緩存少量熱點內存地址的mapping關系。然而由于制造成本和工藝的限制，響應時間需要控制在CPU Cycle級別的Cache容量只能存儲幾十個對象。那么TLB Cache在應對大量熱點數據Virual Address轉換的時候就顯得捉襟見肘了。我們來算下按照標準的Linux頁大小(page size) 4K，一個能緩存64元素的TLB Cache只能涵蓋4K*64 = 256K的熱點數據的內存地址，顯然離理想非常遙遠的。于是Huge Page就產生了。Tips: 這里不要把Virutal Address和Windows上的虛擬內存搞混了。后者是為了應對物理內存不足，而將內容從內存換出到其他設備的技術（類似于Linux的SWAP機制）。
什么是Huge Page既然改變不了TLB Cache的容量，那么只能從系統層面增加一個TLB Cache entry所能對應的物理內存大小，從而增加TLB Cache所能涵蓋的熱點內存數據量。假設我們把Linux Page Size增加到16M，那么同樣一個容納64個元素的TLB Cache就能顧及64*16M = 1G的內存熱點數據，這樣的大小相較上文的256K就顯得非常適合實際應用了。像這種將Page Size加大的技術就是Huge Page。
了解了Huge Page的由來和原理后，我們不難總結出能從Huge Page受益的程序必然是那些熱點數據分散且至少超過64個4K Page Size的程序。此外，如果程序的主要運行時間并不是消耗在TLB Cache Miss后的Page Table Lookup上，那么TLB再怎么大，Page Size再怎么增加都是徒勞。在LWN的一篇入門介紹中就提到了這個原理，并且給出了比較詳細的估算方法。簡單的說就是：先通過oprofile抓取到TLB Miss導致的運行時間占程序總運行時間的多少，來計算出Huge Page所能帶來的預期性能提升。簡單的說，我們的程序如果熱點數據只有256K，并且集中在連續的內存page上，那么一個64個entry的TLB Cache就足以應付了。說道這里，大家可能有個疑問了：既然我們比較難預測自己的程序訪問邏輯是否能從開啟Huge Page中受益。反正Huge Page看上去只改了一個Page Size，不會有什么性能損失。那么我們就索性對所有程序都是用Huge Page好啦。其實這樣的想法是完全錯誤的！也正是本文想要介紹的一個主要內容，在目前常見的NUMA體系下Huge Page也并非萬能鑰匙，使用不當甚至會使得程序或者數據庫性能下降10%。下面我們重點分析。
Large Pages May Be Harmful on NUMA Systems一文的作者曾今做過一個實驗，測試Huge Page在NUMA環境的各種不同應用場景下帶來的性能差異。從下圖可以看到Huge Page對于相當一部分的應用場景并不能很好的提升性能，甚至會帶來高達10%的性能損耗。
性能下降的原因主要有以下兩點
CPU對同一個Page搶占增多對于寫操作密集型的應用，Huge Page會大大增加Cache寫沖突的發生概率。由于CPU獨立Cache部分的寫一致性用的是MESI協議，寫沖突就意味：
類比到數據庫就相當于，原來一把用來保護10行數據的鎖，現在用來鎖1000行數據了。必然這把鎖在線程之間的爭搶概率要大大增加。
連續數據需要跨CPU讀取(False Sharing）從下圖我們可以看到，原本在4K小頁上可以連續分配，并因為較高命中率而在同一個CPU上實現locality的數據。到了Huge Page的情況下，就有一部分數據為了填充統一程序中上次內存分配留下的空間，而被迫分布在了兩個頁上。而在所在Huge Page中占比較小的那部分數據，由于在計算CPU親和力的時候權重小，自然就被附著到了其他CPU上。那么就會造成：本該以熱點形式存在于CPU2 L1或者L2 Cache上的數據，不得不通過CPU inter-connect去remote CPU獲取數據。假設我們連續申明兩個數組，Array A和Array B大小都是1536K。內存分配時由于第一個Page的2M沒有用滿，因此Array B就被拆成了兩份，分割在了兩個Page里。而由于內存的親和配置，一個分配在Zone 0，而另一個在Zone 1。那么當某個線程需要訪問Array B時就不得不通過代價較大的Inter-Connect去獲取另外一部分數據。
delays re-sulting from traversing a greater physical distance to reach a remote node, are not the most important source of performance overhead. On the other hand, congestion on interconnect links and in memory controllers, which results from high volume of data flowing across the system, can dramatically hurt performance.
對策理想Under interleaving, the memory latency re- duces by a factor of 2.48 for Streamcluster and 1.39 for PCA. This effect is entirely responsible for performance improvement under the better policy. The question is, what is responsible for memory latency improvements? It turns out that interleaving dramatically reduces memory controller and interconnect congestion by allevi- ating the load imbalance and mitigating traffic hotspots.
我們先談談理想情況。上文提到的論文其實他的主要目的就是討論一種適用于NUMA架構的Huge Page自動內存管理策略。這個管理策略簡單的說是基于Carrefour的一種對Huge Page優化的變種。（注：不熟悉什么是Carrefour的讀者可以參看博客之前的科普介紹或者閱讀原文）下面是一些相關技術手段的簡要概括：
False Sharing，監控造成大量Cache Miss的Page，并進行拆分重組。將同一CPU親和的數據放在同一個Page中談完了理想，我們看看現實。現實往往是殘酷的，由于沒有硬件級別的PMU(Performance Monitor Unit)支持，獲取精準的Page訪問和Cache Miss信息性能代價非常大。所以上面的理想僅僅停留在實驗和論文階段。那么在理想實現之前，我們現在該怎么辦呢？答案只有一個就是測試
實際測試實際測試的結果最具有說服力。所謂實際測試就是把優化對象給予真實環境的壓力模擬。通過對比開啟和關閉Huge Page時的性能差別來驗證Huge Page是否會帶來性能提升。當然大多數應用程序，要想模擬真實環境下的運行情況是非常困難的。那么我們就可以用下面這種理論測試
理論測試理論測試可以通過profile預估出Huge Page能夠帶來的潛在提升。具體原理就是計算當前應用程序運行時TLB Miss導致的Page Walk成本占程序總執行時間的占比。當然這種測試方式沒有把上文提到的那兩種性能損失考慮進去，所以只能用于計算Huge Page所能帶來的潛在性能提升的上限。如果計算出來這個值非常低，那么可以認為使用Huge Page則會帶來額外的性能損失。具體方法見LWN上介紹的方法具體的計算公式如下圖：
如果沒有hardware的PMU支持的話，計算需要用到oprofile和calibrator。
并不是所有的優化方案都是0性能損失的。充分的測試和對于優化原理的理解是一個成功優化的前提條件。
Reference新聞熱點
疑難解答
