理想的 huge page

背景

　　现代计算机的内存越来越大，服务器动辄就有上百GB，甚至 TB 级别的内存，很多应用已经可以把全部数据都放入内存，这样，磁盘空间换取内存空间这个传统中虚拟内存最重要的需求已经相当弱化甚至不复存在。当然我们仍然需要虚拟内存的其它好处（进程隔离、内存保护等），但是，虚拟内存最大的缺点：地址转换开销，在很多应用中越来越突出。

　　于是，大家想起了 huge page ，huge page 大幅减小了对 CPU 中 TLB 的需求，在某些特殊应用中可以大幅提高性能，在我们的数据库测试中，huge page （还只是 2MB 的hugepage）提高了 40% 的性能。

　　目前 huge page 在各平台上的使用很麻烦，并且有很多限制，比如 Linux 上只有私有匿名 page 可以使用 huge page，windows 上使用 huge page (large page) 除了需要私有匿名，还需要特殊权限。

理想中的 huge page 应该是这样的：

1. 超大 huge page (比如 1GB 的 huge page) 最好通过系统启动参数保留
   • 跟现在一致，不过可以 relax 一下，如果启动参数中未保留，如果系统通过 defrag 可以回收到连续的超 1G 的物理内存，仍可使用
   • 现有 page 实现都需要 page 物理地址按 pagesize 对齐（硬件需求），但是对超大 huge page，我觉得这个需求可以放宽一点，虚拟地址按 pagesize 对齐，物理地址可以只按某个较小的值对齐
2. Linux transparent huge page 已经做得相当不错了，但是好像不支持 1GB 的 huge page，如果能 transparent 1GB 的 huge page，就更好了
3. Readonly, 并且 Lock 的非匿名非私有 mmap，应该也可以“尽最大努力”使用尽可能大的 huge page
   • 要更严格一点，如果某个文件某区域已经这样使用了 huge page，后续在同一文件同一（可能交叉）区域的 mmap 与 Readonly & Lock 不兼容，后续的这个 mmap 调用可以失败，这种 case 应该不多，并且大概率是错误的用法，失败完全可以接受。
   • 尽量用更大的（比如 1GB）的 huge page
4. 硬件厂商应该也与时俱进，huge page 的 TLB 可以适当增加一些