Hugepages的前世今生 （四）

原文链接： http://www.dbaleet.org/the_cirle_of_hugepages_part_4

有同学看完我前面三篇文章问到： 虽然内容很多，但是比较零散，我仍然不是太清楚为什么一定要用hugepages，能介绍一下使用hugepages的好处吗? Stay tuned, this is exactly what this article about.

看上去前人之述备矣，我本打算丢一个文档号（ MOS文档 HugePages on Linux: What It Is… and What It Is Not… [ID 361323.1] ）或者网上对这篇文章的翻译给他，但是考虑到网上这篇文档的翻译并不能很清楚地解释更深层次的原因，大多数只是列举了一些事实，所以写下了这篇文章。注意以下是我个人对这篇文档的一些理解，本人力求准确，但是毕竟水平有限，难免出现一些遗漏甚至错误。

• Not swappable （使得SGA不可交换）

为啥SGA是可以被换到虚拟内存的？？？ The fact is that

Bug 160033 – Kernel swaps out Oracle instead of releasing cache

这个bug最终关闭的状态为Not a bug, 但是同时在这个bug中提到：

The basic design of the VM in RHEL 4 and RHEL 5 will not allow a complete fix for this issue, only tweaks to make it behave better most of the time.

In the upstream kernel (and for RHEL 6), this problem has been addressed with the split LRU VM, which was merged in 2.6.28 and continues to get small fixes and tweaks.  In RHEL 6 this issue should be resolved.

Oracle SGA区的内存被swap到磁盘只有到Linux Kernel2.6.28或者RHEL 6以后才通过引入新的机制得到解决。而一旦SGA区被换出内存会造成很大的性能抖动。所以在这个问题彻底解决之前，绝大多数版本的Linux依然需要通过hugepages来固定SGA区。（Linux平台并不支持通过设置lock_sga和参数的方法来固定SGA， pre_page_sga这个参数存在太多的弊端已经强烈不推荐使用）

• • • • • Relief of TLB pressure: （减轻TLB的压力）

在第一篇文章中我们知道TLB是直接缓存虚拟地址到物理地址的缓存表，用于提升性能，省去查找page table减少开销，但是如果出现的大量的TLB miss，必然会给系统的性能带来较大的负面影响，尤其对于连续的读操作。从第二篇文章中我们知道如果使用hugepages能大量减少PTE的数量，也就意味着访问同样多的内容需要的PTE会更少，而通常TLB的槽位是有限的，一般只有512个，所以更少的PTE也就意味着更高的TLB的命中率。

• • • • Decreased page table overhead: （减少页表的开销）

在第二篇文章中，我们通过计算，对4k page和hugepages的页表开销的进行对照发现，使用hugepages可以极大的减少维护页表的开销。这篇文章中也提到了一个计算方法：

 Each page table entry can be as large as 64 bytes and if we are trying to handle 50GB of RAM, the pagetable will be approximately 800MB in size which is practically will not fit in 880MB size lowmem (in 2.4 kernels - the page table is not necessarily in lowmem in 2.6 kernels) considering the other uses of lowmem. When 95% of memory is accessed via 256MB hugepages, this can work with a page table of approximately 40MB in total. See also Document 361468.1

注意这里说PTE为64Bytes是一种最极端的情况，考虑的是极值，所以实际上这种估算方法并不是太合理。 前面说过：一般来说x86的PTE的大小为4Bytes， x86_64的PTE的大小为8Bytes， 这里说的PTE为64Bytes实际上指的是由8个PTE组成的PTEG（PTE group），在《Microprocessor 8085, 8086》这本书的425页中提到A PTEG contains eight Page Table Entries (PTEs) of eight bytes each

• • • • .
        • Eliminated page table lookup overhead: （减少页表查询的开销）

PTE的数量减少，那么使得很多页表的查询就不需要了，并且更少的PTE使得页表的查询更快。如果TLB miss，则可能需要额外三次内存读取操作才能将线性地址翻译为物理地址。

• • • • • Faster overall memory performance: （提升内存访问的整体性能）

现代操作系统都是使用虚拟内存管理，每一次对内存的访问实际上都是由两次抽象的内存操作组成。如果只要使用更少的页面，那么原本在页表访问的瓶颈也得以避免。

下一篇将介绍不使用hugepages所带来的问题中的一个非常典型的案例。