当在cpu上设置PDPE标志时，X86和x64处理器允许1GB页面。在什么应用中这是实用的还是需要的以及出于什么原因？
答案 0 :(得分：2)
如果内存占用大，内存访问模式跨越大距离（跨4K页面），Hugepage会有所帮助。
它不仅可以减少TLB未命中，还可以节省OS mm系统页表大小。
一个很好的例子是数据包处理。在高吞吐量网络应用（1Gbps或更高）中，分组通常存储在分组缓冲池中（即池化技术）。例如，每个数据包缓冲区的大小为2KB，池中包含512个缓冲区。此数据包缓冲池的访问模式可能不是顺序的（缓冲区索引为1,2,3,4,5 ......），而是随时间随机变化（1,104,407,45,905 ...）。由于正常页面大小为4K，因此普通TLB在这里没有帮助，因为每次数据包访问都会导致TLB未命中，并且有很多不同的缓冲区位于不同的页面上。
相反，如果你把池放在一个1GB的巨页中，那么所有的数据包缓冲区共享相同的hugepageTLB条目，从而避免错过。
这用于DPDK（数据平面开发工具包）中的数据包 在TLB未命中时浪费的周期率非常高。
使用的大内存池分配需要Hugepage支持 对于数据包缓冲区（必须在中启用HUGETLBFS选项） 运行内核，如上一节所示）。通过使用hugepage 分配，性能提高，因为需要的页面更少， 因此较少的翻译旁视缓冲区（TLBs，高速 翻译缓存），减少翻译时间 虚拟页面地址到物理页面地址。没有大页面， 标准的4k页面大小会出现高TLB未命中率， 性能下降。
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#bios-setting-prerequisite-on-x86
Oracle的另一个例子：
...当大页面没有时，几乎6.8 GB的内存用于页表 配置...
...在Oracle数据库分配和使用大页面之后。页表开销减少到略低于23 MB
http://www.databasejournal.com/features/oracle/understanding-hugepages-in-oracle-database.html
相关链接：
https://en.wikipedia.org/wiki/Object_pool_pattern
- 编辑 -
但是，应谨慎使用largepage。上面我提到内存池将受益于1GB的巨页。但是，如果您在1GB页面边界上拥有访问模式，那么它可能没有帮助。有一个很好的博客：
答案 1 :(得分：0)
想象一下使用大量内存的应用程序 - 分子建模。天气预报 - 特别是如果它没有用户交互。
大页面：
（1）减少页表开销内存的数量 （2）增加可以存储在MMU缓存中的内存量。 （相同数量的缓存条目引用更多内存）。
答案 2 :(得分：0)
我的戴尔安装了LabView，配备8核和16GB DDRM，驱动4 24和34＃;监视器。
如果我创建一个大多数类型的视频处理器或合成器，使用1024px x 1024px＆＃39;绘图＆＃39;显示，LabView在我开始复合之前预留了1.5GB。它是用C和C ++构建的。
我经常将图像细节存储在256 x 256 x 256 U32整数的3D数组中，这些整数保存每个RGB像素颜色，加上不透明或遮蔽的alpha通道。每层缓冲视频的容量为64MB。如果我需要记住128层，那就是8GB。
LabView是一个类似于CAD程序的编程语言。如果我需要8GB用于一系列视频（HDTV）缓冲区，那就是它给我的东西，等待malloc完成其工作几秒钟。
如果我创建了一个8GB的3D阵列一个数据库，即使我在MySQL（而不是数组）中做到这一点也没有什么不同。对我而言，拥有许多千兆字节的内存是常态，而不是例外。