Memory 哪些应用程序需要1GB页面？

在cpu上设置PDPE标志时，X86和x64处理器允许1GB页面。在什么样的应用中，这是实际的或需要的？出于什么原因？

想象一个使用大量内存分子建模的应用程序。天气预报，尤其是在没有用户交互的情况下

大页面：

（1） 减少页表开销内存量

---

（2） 增加可存储在MMU缓存中的内存量。（相同数量的缓存项引用更多的内存）。

Hugepage将有助于解决内存占用较大且内存访问模式跨越较大距离（跨越4K页）的情况

它不仅减少了TLB未命中，而且还节省了OS mm系统页表的大小

一个很好的例子是数据包处理。在高吞吐量网络应用（1Gbps或更高）中，数据包通常存储在数据包缓冲池中（即池技术）。例如，每个数据包缓冲区的大小为2KB，池包含512个缓冲区。此数据包缓冲池的访问模式可能不是顺序的（缓冲区索引为1,2,3,4,5…），而是随时间随机的（1104407,45905…）。因为正常的页面大小是4K，所以正常的TLB在这里没有帮助，因为每个数据包访问都会导致TLB丢失，并且在不同的页面上有很多不同的缓冲区

相反，如果将池放在1GB的hugepage中，则所有数据包缓冲区共享相同的hugepageTLB条目，从而避免未命中

这在DPDK（数据平面开发工具包）中使用，其中数据包 TLB未命中的周期浪费率非常高，不可忽略

使用的大型内存池分配需要Hugepage支持 对于数据包缓冲区（必须在 如前一节所示运行内核）。使用hugepage 由于需要更少的页面，因此性能得到了提高， 因此，转换查找缓冲区（TLB，高速 翻译缓存），从而减少翻译文件所需的时间 将虚拟页地址转换为物理页地址。没有雨伞， 使用标准4k页面大小时，TLB未命中率会很高， 性能下降

Oracle的另一个示例：

…当不使用hugepages时，页表使用了近6.8GB的内存 配置的

…在Oracle数据库分配和使用hugepages之后。页面表开销减少到略小于23MB

相关链接：

--编辑--

但是，应小心使用hugepage。上面我提到内存池将受益于1GB的hugepage。然而，如果您有一个跨1GB页面边界的访问模式，那么它可能没有帮助。在这方面有一个很好的博客：

---

我在Dell ws上安装了LabView，具有8个内核和16GB DDRM，驱动4 24小时“监视器。
如果我创建了一个视频处理器或任何类型的合成器，具有1024px 1024px‘绘图’显示，LabView甚至在开始合成之前就保留了1.5GB。它是由C和C++构建的。
BR/>我经常把图像细节存储在256×256×256的3D数组中，其中U32整数包含每个RGB像素颜色，加上alpha通道用于不透明度或遮蔽。每层缓冲视频64MB。如果我需要记住128层，那就是8GB。

LabView是一种编程语言，其结构非常类似于CAD程序。如果我需要8GB用于一系列视频（HDTV）缓冲区，这就是它将给我的，只需几秒钟等待malloc完成它的工作。

如果我为数据库创建了8GB 3D阵列，即使我是在MySQL中创建的（而不是作为阵列）。对我来说，有很多GB的ram可供使用是正常的，而不是例外。

很难想象任何需要它的应用程序。“有益”可能是一个更好的术语，适用于1）1GB页面完全满了，或者几乎满了，从而减少了浪费的空间；2）页面表和TLB条目中存在大量混乱-较大的页面意味着每GB内存所需的条目较少，这样就减少了虚拟内存硬件/软件的压力。对于罕见的情况，它似乎是一个特殊的大小。经过研究，考虑到大多数页面大小为4096字节（至少默认情况下），我找不到任何需要如此大页面大小的内容。