profiler - 在 x86-64 中测量 TLB 未命中处理成本

标签 profiler performancecounter tlb mmu

我想估计由于运行 Linux 的 x86-64(英特尔 Nehalem)机器上的 TLB 未命中而导致的性能开销。我希望通过使用一些性能计数器来获得这个估计。有没有人对估计这个的最佳方法有一些指示?

谢谢
阿尔卡

最佳答案

如果您可以访问基于“Westmere”的系统,您的代码的性能特征应该与您在“Nehalem”上的非常相似,但是您将可以访问一个新的硬件性能计数器事件,该事件几乎可以准确地测量您的性能想。

在 Westmere 上,等待处理 TLB 未命中时性能损失的最佳估计可能来自硬件性能计数器 Event 08H, Mask 04H“DTLB_LOAD_MISSES.WALK_CYCLES”,它被描述为计数“Cycles Page Miss Handler is busy with a page由于二级 TLB 中的负载未命中而行走”。
这在“英特尔® 64 位和 IA-32 架构软件开发人员手册
第 3B 卷:系统编程指南,第 2 部分”(文档编号:253669),可在线获取:
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.html

这个事件是必要的原因是 TLB 未命中处理时间由读取包含页表条目的缓存行所需的时间决定。如果该缓存行位于 L2 缓存中,则 TLB 未命中的开销将非常小(大约 10 个周期)。如果该行在 L3 缓存中,则可能需要 25 个周期。如果该行在内存中,则 ~200 个周期。

  • 如果上层页面转换缓存中也存在未命中,则需要多次访问内存才能找到并检索所需的页表条目(例如, https://stackoverflow.com/a/9674980/1264917 )。
  • 在某些处理器上,L2 缓存计数器可以告诉您在 L2 中命中和错过了多少表遍历,但在 Nehalem 上则不然。 (在这种情况下它不会有很大帮助,因为在 L3 中命中的 TLB 遍历也相当快,而您真正想要的是必须转到内存的 TLB 遍历。)
  • 关于profiler - 在 x86-64 中测量 TLB 未命中处理成本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9338236/

    相关文章:

    iphone - 如何通过 iPhone 设备使用 Time Profiler 仪器

    asp.net - 安装 .net 4.5 后,某些性能计数器显示错误值

    c++ - 如何使用性能计数器控制从文件中读取?

    c# - 检查当前和外部 .Net 进程是否启用了性能计数器?

    c# - EQATEC 分析器与 DotTrace 相比如何?

    reactjs - 子组件的统计信息并不总是在 Chrome 性能选项卡的用户计时部分中可用

    TLB(加载字)异常是否会因错误的编译器选项使用而引起?

    c - 尝试刷新缓存时出现段错误(核心转储)错误

    performance - AMD:TLB 未命中周期的性能计数器

    performance - AQTime 是如何做到的?