Linux下用戶空間的可執行程序代碼段、數據段以及堆棧空間可否安置在hugepage中？

01-29

通過少量的TLB項，達到指定程序在用戶空間運行時完全避免訪問代碼段、數據段或者堆棧時的TLB缺失，毫無下限的將性能做到上限；
不考慮裸核的方式，必須是一個linux用戶進程
不改內核，是否已可以支持？如果修改內核，有什麼較好的方式？

我最早接觸HugeTLB是在某MIPS的方案中，好像當時特性的名字叫BigTLB， @唐浩然說到的2M太小兒科了，那個方案的HughTLB是512M起跑的。當時使用的是一種靜態的配置方法，在Fork還是Exec的時候指定特定的參數，就可以分別給不同的段指定固定大小的TLB項，而且鎖死在TLB中，這種進程在整個運行過程都不會缺頁的。

提供那個方案的公司當時說他們在做上傳，結果過了幾年，HugeTLB上去了，BigTLB消失了，我對此的理解是：其實代碼段不缺頁其實意義不大，代碼的局部性還是很強的，代碼段完全沒有必要佔用寶貴的大頁TLB項，只要保證分配大量數據內存的時候這樣做即可，這種模型極其適合在類似資料庫這樣的應用中。

HugeTLB很好地嵌入到了當前的page管理框架中，它不修改page的大小（仍是4K），但HugeTLB的第一個page有一個標記說明它是HugeTLB，後續的page就會無效。所以，僅僅TLB刷新的位置需要理解這是一個hugetlb。

HugeTLB提供多個分配和使用的介面，這些可以直接參考內核文檔vm/hugetlb.txt。

我不太清楚這塊，但是你放到一起怎麼進行許可權保護呢？比如txt不可修改但stack是可以的，原則上需要進行區分且只能按照頁為單位，所以這塊是肯定不行的。另外效率問題大多集中在演算法和cache不命中的問題上，還不到tlb這一級別。kvm據說可以用巨頁提高效率，但這也是比較特別的情況。

Linux已經支持巨頁，你可以查一下文檔

先看看這個：Linux 大頁面使用與實現簡介

1：其中說 hugepage只是將pmd 直接指向了2M大小的頁面（而不是指向pte）. 這樣的話，在內核中page_size基準沒有發生改變,且pdg_shift, page_shift,pmd_shift, pud_shift,這樣變數仍然是以 4k的page為基準而設置。

2：用戶進程的 pcb /task_struct 都是由內核管理，對用戶 vm_area管理的頁面分配也是按4k為基準,，所以用戶線性區的代碼段，數據段，的頁面分配都是page_size的頁面。

3：如果想實現你所說的，用戶程序代碼段，數據段，使用較大的 page_size,看來是需要修改內核page_size ，以及其他所有與page_size相關的數據結構。

4，且分頁是Linux對內存空間管理的根基，理論上說所有基於分頁的內核內容都需要修改，感覺這個工作量還是很大的。

上面的貼出的鏈接中，那個作者說他做過嘗試：「但如何做到對傳統應用程序的完全透明性和與其它內核模塊的兼容性，是實現上的難點。筆者在寫作本文之前曾試圖通過修改 Linux 內核中定義頁面大小的宏（PAGE_SIZE）來實現透明的大頁面支持，但內核中某些部分的代碼僅僅支持 4KB 的頁面大小，使得內核編譯都無法通過，即使經過適當的修改勉強編譯通過，內核也無法正常啟動。因此可以預見的是，實現 Linux 內核透明的大頁面支持將是一項繁雜的工作。」

如果不修改程序和kernel，你可以搜搜transparent hugepage。這個是Linux已有的功能。

目前hugepage只支持anonymous pages，而stack和heap是由anonymous page組成的，自然是可以是hugepage的。

而代碼和全局數據屬於file-backed page，而file-backed page目前不支持hugepage，所以代碼和全局數據暫時不支持hugepage。

如果是hugetlbfs，這個需要程序用對應的庫，程序需要修改。同時，操作系統也要加對應的參數，事先分出一部分內存作為hugepage專用。

目前當然有正在進行的工作來使得file-backed page支持hugepage，可以搜搜DAX(direct access excutable)在ext4上的支持。這個主要是用來支持NVM的。