下面用例子來說明爲什麼使用傳統的 4k大小的頁表相比hugepages對大內存的管理效率會很低。
some facts: 在x86平臺，一條PTE的大小爲4Byte；而在x86_64平臺， 一條PTE的大小爲8Byte。
以下這種場景並不罕見：
Linux x86_64, SGA大小爲100G， 使用常規的4k的page，連接到數據庫的進程數約1000。
page table一共需要100×1024×1024K/4K=26214400條PTE；
那麼26214400條PTE需要100×1024×1024K/4K×8Byte=209715200Byte=200M；
從而1000個進程需要100×1024×1024K/4K×8Byte×1000=209715200000Byte=200G。
計算出來的結果真是令人崩潰，但是事實上在你沒有崩潰以前， 數據庫就已經因爲沒有內存而崩潰了。
同樣條件下，如果使用2M的hugepages進行對比， 則以上的計算方法變爲：
page table一共需要100×1024M/2M=51200條PTE；
那麼51200條PTE需要100×1024M/2M×8Byte=409600Byte=400K；
從而1000個進程需要100×1024M/2M×8Byte×1=409600Byte=400K。
是的，你沒有看錯，只要乘以1，而不是乘以1000。
綜上，可以看到同樣是1000個進程，同樣是管理100G的SGA，結果卻大不相同。
使用傳統的4k大小的page開銷竟然會達到驚人的200G；
而使用2M的hugepages，開銷只有400K。
這其中不僅僅只是對於因爲單個進程而言，2M page需要的PTE小於4K page的PTE， 最大的一個原因是在於使用4K page的話，有多少進程使用SGA， 就需要多少套PTE，相反如果使用2M page則無論有多少進程使用SGA，共享的都是同一套PTE。
注： 此問題曾經困惑了我很長時間，在公司Linux PM的幫助下終於弄懂了這個算法，這裏表示誠摯的感謝，當然希望對本文的讀者能有一些幫助。
Hugepages really make some differents。