记录 Linux 中任何可执行文件/进程的所有内存访问答案

【问题标题】：Logging all memory accesses of any executable/process in Linux记录 Linux 中任何可执行文件/进程的所有内存访问
【发布时间】：2017-10-20 05:27:18
【问题描述】：

我一直在寻找一种方法来记录 Linux 中进程/执行的所有内存访问。我知道以前在这里有人就这个话题提出过这样的问题

Logging memory access footprint of whole system in Linux

但我想知道是否有任何非仪器工具可以执行此活动。我不为此目的寻找 QEMU/VALGRIND，因为它会有点慢，我希望开销尽可能少。

为此，我查看了perf mem 和cpu/mem-loads/pp 之类的PEBS 事件，但我发现它们只会收集采样数据，而我实际上想要在没有任何采样的情况下跟踪所有内存访问。

我想知道是否有可能通过使用像 QEMU 这样的工具来收集所有内存访问而不会浪费太多开销。是否有可能只使用 PERF 但没有样本，以便我获得所有内存访问数据？

还有其他我缺少的工具吗？或者任何其他可以为我提供所有内存访问数据的策略？

【问题讨论】：

你要记录多长时间的过程？它运行1秒吗？它多久有一次内存访问指令，大约每 3 条指令中的 1 条？因此，您将（假设具有 IPC~1 的 3Ghz CPU）有 1 000 000 000 次内存访问，每次访问大约有 8 个字节的元数据（类型，48-52 位的目标地址） - 这是 8 GB！ 您无法在没有开销的情况下记录程序的所有内存访问（没有非常昂贵的 20k USD+ 硬件嗅探器）。您可以使用 PT/perf 对其中的 1/1000 或 1/100000 进行采样；或者您可以使用 valgrind 或 qemu 或其他模拟器以 10x-20x-50x 减速记录所有内容。
嗨@osgx，我专门寻找spec2006程序（运行时间最长的程序可能是8分钟-我认为这会非常大）。这意味着我不能拥有任何其他工具。如果我想记录所有内存访问，我需要使用硬件嗅探器吗？除此之外，如果我真的想避免开销，我没有其他选择。
嗨@osgx，有什么方法可以使用 perf/pt/pebs 来收集所有内存访问样本而不进行采样？还是我完全遵循不同的策略？
为什么要避免任何开销？（对于 10 分钟的程序和 10 倍的开销，您将等待 2 小时，这比在这里等待答案要快。）你有钱吗？购买硬件嗅探器（您需要 JTAG 嗅探器 XDP blog.asset-intertech.com/test_data_out/2016/07/… 来获取对缓存的所有访问，或者需要总线/ddr 嗅探器来获取真正的内存访问）？你能估计一下有多少次访问以及写下来需要多少？为什么要记录每个内存访问？
我想知道它是否真的可以在没有任何开销的情况下实现。我们正试图看到这一点。我们想要每次内存访问没有确切的理由，但我们正在尝试测量记录所有内存访问的开销。我们的程序中有很多内存访问事件。（可能达到数百万）。到目前为止，我们对使用任何硬件嗅探器都不感兴趣。

标签： linux memory processor perf

【解决方案1】：

不可能同时尽可能快地运行 Spec 并在此运行中跟踪所有内存访问（或缓存未命中）（使用系统内跟踪器）。一次运行以进行计时，另一次运行（更长，更慢），甚至重新编译二进制文件以进行内存访问跟踪。

您可以从简短的程序（不是最近的 SpecCPU 的 ref 输入，或您的大型程序中的十亿内存访问）开始并使用perf linux 工具 (perf_events) 查找记录的内存请求与所有内存请求的可接受比率。有perf mem 工具，或者您可以尝试一些内存子系统启用PEBS 的事件。通过将 :p 和 :pp 后缀添加到 perf 事件说明符 perf record -e event:pp 来启用 PEBS，其中 event 是 PEBS 事件之一。还可以尝试pmu-tools ocperf.py 以更轻松地进行英特尔事件名称编码并查找启用了 PEBS 的事件。

尝试在内存性能测试中找出不同记录比率（1% / 10% / 50%）的实际（最大）开销。在 [Roofline model](https://crd.lbl.gov/departments/computer-science/PAR/research/roofline/ 的 Arithmetic Intensity scale 左侧检查内存记录开销的最坏情况。这部分的典型测试是：STREAM (BLAS1)、RandomAccess (GUPS) 和 memlat 几乎是 SpMV；许多实际任务通常不会在秤上留下这么多：

STREAM test (linear access to memory),
RandomAccess (GUPS) 测试
一些内存延迟测试（memlat of 7z、lat_mem_rd of lmbench）。

您想跟踪每个加载/存储命令，还是只想记录错过所有（某些）缓存并发送到 PC 主 RAM 内存（到 L3）的请求？

为什么您不希望任何开销并记录所有内存访问？这是不可能的，因为每个内存访问都跟踪几个字节（内存地址，有时：指令地址）要记录到同一个内存中。因此，启用内存跟踪（超过 10% 或内存访问跟踪）显然会限制可用内存带宽，并且程序运行速度会变慢。甚至可以注意到 1% 的跟踪，但它的影响（开销）较小。

您的 CPU E5-2620 v4 是 Broadwell-EP 14nm，因此它可能还有一些早期版本的 Intel PT：https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/intel-pt.txt https://github.com/01org/processor-trace，尤其是 Andi Kleen 在 pt 上的博客：http://halobates.de/blog/p/410"带有 Linux perf 和 gdb 的 Intel Processor Trace 备忘单"

硬件中的 PT 支持：Broadwell（第 5 代核心，至强 v4）更多开销。没有细粒度的时机。

PS：研究 SpecCPU 进行内存访问的学者使用内存访问转储/跟踪，转储生成缓慢：

http://www.bu.edu/barc2015/abstracts/Karsli_BARC_2015.pdf - LLC 未命中记录到离线分析，没有记录跟踪运行的时间
http://users.ece.utexas.edu/~ljohn/teaching/382m-15/reading/gove.pdf - 所有加载/存储都通过写入额外的巨大跟踪缓冲区以定期（罕见）在线聚合来检测。此类检测速度慢 2 倍或更慢，尤其是对于内存带宽/延迟受限的内核。
http://www.jaleels.org/ajaleel/publications/SPECanalysis.pdf（由 Intel Corporation 的 Aamer Jaleel，VSSAD） - 基于引脚的检测 - 修改和检测程序代码以将内存访问元数据写入缓冲区。这种检测速度慢 2 倍或更慢，特别是对于内存带宽/延迟受限的内核。该论文列出并解释了仪器开销和注意事项：

仪器开销：仪器涉及将额外的代码动态或静态注入目标应用。附加代码会导致应用程序花费额外的时间来执行原始应用程序...此外，对于多线程应用程序，仪器可以修改排序不同线程之间执行的指令应用。因此，具有多线程的 IDS 应用程序缺乏保真度

缺乏推测：仪器只观察在正确的执行路径上执行的指令。作为结果，IDS 可能无法支持错误路径...

仅限用户级流量：当前的二进制检测工具仅支持用户级检测。因此，内核密集型应用程序不适合用户级IDS。

【讨论】：