大页面在什么情况下可以产生加速？

现代x86 CPU能够支持比传统4K（即2MB或4MB）更大的页面尺寸，并且有操作系统工具（Linux，Windows）可以访问此功能。大页面在什么情况下可以产生加速？

上面的Microsoft链接指出大页面“提高了翻译缓冲区的效率，这可以提高经常访问的内存的性能”。这对于预测大页面是否可以改善任何特定情况并无大帮助。我对具体（最好是量化的）例子感兴趣，在这些例子中，将某些程序逻辑（或整个应用程序）移动到使用大页面会导致一些性能改进。任何人都有成功的故事吗？

我知道myself有一个特定情况：使用巨大的页面0123'可以减少分叉大型进程所需的时间（假设需要复制的TLB记录数减少1000倍）。我很感兴趣的是，巨大的页面是否也可以在不那么奇特的场景中获益。

来源

2010-05-20 timday

我试图设计一些代码，以最大化4k页面的TLB抖动，以检查大页面可能带来的收益。当2MByte页面由libhugetlbfs的malloc（Intel i7,64位Debian Lenny）提供时，下面的东西运行快2.6倍（比4K页面）;希望明显是什么scoped_timer和random0n做。

volatile char force_result; 

    const size_t mb=512; 
    const size_t stride=4096; 
    std::vector<char> src(mb<<20,0xff); 
    std::vector<size_t> idx; 
    for (size_t i=0;i<src.size();i+=stride) idx.push_back(i); 
    random0n r0n(/*seed=*/23); 
    std::random_shuffle(idx.begin(),idx.end(),r0n); 

    { 
    scoped_timer t 
     ("TLB thrash random",mb/static_cast<float>(stride),"MegaAccess"); 
    char hash=0; 
    for (size_t i=0;i<idx.size();++i) 
     hash=(hash^src[idx[i]]); 
    force_result=hash; 
    }

一个更简单的“直线”版本只有hash=hash^src[i]只能从大的页面上涨16％，但（漫天要价）英特尔fancy prefetching hardware可帮助时访问是可以预见的（4k的情况下，我想我可以disable prefetching调查不管那是真的）。

来源

2010-05-21 18:43:03 timday

硬件预取不会跨越4k页面边界，但是您可能在直线情况下看到的是页面表访问是非常可预测的，所以当您在TLB中错过时发生的页面遍历可能会打到都在L1中（这些页面条目可能确实是通过预取引入的）。 – BeeOnRope 2014-08-26 04:14:10

我在某些HPC /网格场景中看到了改进 - 特别是在拥有大量RAM的机器上具有非常非常大的模型的物理包。运行模型的进程也是机器上唯一活动的东西。我怀疑，尽管没有衡量，某些数据库功能（例如大宗进口）也会受益。我个人认为，除非你有一个非常好的/明白的内存访问配置文件，并且它有很多大的内存访问，否则你不会看到任何显着的改进。

来源

2010-05-20 20:49:11

在运行大型进程的大量内存（> = 64GB）的服务器上，我获得了大约5％的加速比。例如对于16GB的Java进程，这是4M x 4kB页面，但只有4k x 4MB页面。

来源

2010-05-21 07:23:01

当您对大范围内存进行宽间隔的随机访问时，性能上最大的差异将会出现 - 其中“大”意味着远大于可由所有小页面条目映射的范围TLB（通常在现代处理器中具有多个级别）。

为了使事情更加复杂，4kB页面的TLB条目数量通常大于2MB页面的条目数量，但这种差异很大程度上取决于处理器。在Level 2 TLB中有多少“大页面”条目也有很多不同。

例如，在AMD Opteron系列10H修订d（ “伊斯坦布尔”）系统，CPUID报告：

L1 DTLB：4KB页：48个条目; 2MB页面：48个条目; 1GB页面：48个条目
L2 TLB：4kB页面：512个条目; 2MB页面：128条目; 1GB的网页：16个条目

虽然在Intel Xeon处理器56XX（ “Westmere的”）系统，CPUID报告：

L1 DTLB：4KB页：64个条目; 2MB pages：32 entries
L2 TLB：4kB pages：512 entries; 2MB的网页：无

两者都可以使用患2 TLB未命中水平之前小网页，而Westmere的系统可以使用其32个2MB TLB条目映射64MB和AMD系统可使用映射352MB映射2MB（512 * 4kB的）其L1和L2 TLB中的176个2MB TLB条目。通过使用大页面进行随机访问，系统将获得显着的加速，这些内存范围远远大于2MB且小于64MB。 AMD系统应该继续使用大页面来显示更好的性能，以获得更大的内存范围。

在所有这些情况下，您试图避免的是最糟糕的情况（注1）遍历x86_64分层地址转换的所有四个级别的情况。
如果没有地址转换缓存机制的（注2）的工作，它要求：

5趟内存加载映射4KB的页面上的数据，
4趟内存加载映射数据一个2MB的页面和
3次访问内存加载映射在1GB页面上的数据。

在每种情况下的最后一趟内存是获得所请求的数据，而需要的其他车次获得的页面转换信息的各个部分。我见过的最好的描述是在AMD公司的第5.3节“AMD64架构程序员手册第2卷：系统编程”（出版物24593）http://support.amd.com/us/Embedded_TechDocs/24593.pdf

注1：上述数字是不是真的最坏情况。在虚拟机下运行会使这些数字变得更糟。在导致持有不同级别的页表的内存交换到磁盘的环境中运行，使性能更差。注2：不幸的是，即使知道这个级别的细节还不够，因为所有现代处理器都有用于页面转换层次结构上层的额外缓存。据我所知，这些在公共场合记录很差。

来源

2012-03-12 21:20:05 user1264917

这变得越来越深奥，但是在进行DMA内存传输时（从主机通过PCIe到主机），巨大的TLB页面对英特尔至强融核（MIC）架构产生了重大影响。 This Intel link describes how to enable huge pages。我发现，一旦传输大小达到512 MB，正常TLB页面大小（4K）以上的DMA传输大小超过8 MB时开始降低性能，从大约3 GB/s降至1 GB/s以下。

启用巨大的TLB页面（2MB）后，512 MB的DMA传输的数据速率继续增加至超过5 GB/s。

来源

2014-10-15 23:46:30

大页面在什么情况下可以产生加速？

回答

相关问题