loggingLinux中所有可执行文件/进程的内存访问

我一直在寻找一种方法来logging在Linux中进程/执行的所有内存访问。 我知道以前在这个问题上有关于这个话题的问题

在Linux中logging整个系统的内存访问占用情况

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

为了这个目的,我查看了perf mem和PEBS事件,例如cpu/mem-loads/pp ,但是我发现它们只会收集采样数据,实际上我想要所有内存访问的跟踪而没有任何采样。

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

有没有其他的工具,我失踪了? 或者任何其他策略,给我所有的内存访问数据?

Solutions Collecting From Web of "loggingLinux中所有可执行文件/进程的内存访问"

在这个运行中(使用在系统跟踪器)追踪Spec和所有内存访问(或缓存未命中)的速度可能是最快的。 是否运行计时和其他运行(更长,更慢),甚至重新编译二进制内存访问跟踪。

你可以从简单和简单的程序开始 (不是最近的SpecCPU的引用输入,或者你的大程序中的十亿次访问),并使用perf linux工具 (perf_events)来查找记录到所有内存请求的可接受内存请求比率。 有perf mem工具,或者你可以尝试一些PEBS启用的内存子系统的事件。 通过在perf事件说明符perf record -e event:pp添加:p:pp后缀来启用PEBS,其中事件是PEBS事件之一。 也可以尝试使用pmu-tools ocperf.py来简化英特尔事件名称编码并查找已启用PEBS的事件。

尝试在内存性能测试中找到具有不同记录率(1%/ 10%/ 50%)的实际(最大)开销。 在[Roofline model]( https://crd.lbl.gov/departments/computer-science/PAR/research/roofline/)的算术强度等级上的左边部分检查最坏的记录记录开销。这部分的典型测试是:STREAM(BLAS1),RandomAccess(GUPS)和memlat几乎是SpMV;许多真正的任务通常不会那么大:

  • STREAM测试(线性访问内存) ,
  • RandomAccess(GUPS)测试
  • 一些内存延迟测试( 7z的memlat , lmbench的lat_mem_rd )。

你想跟踪每一个加载/存储命令,或者你只想记录错过所有(一些)缓存并发送到PC的主RAM内存(到L3)的请求吗?

为什么你不想开销和所有的内存访问记录? 这是不可能的,因为每个存储器访问都跟踪几个字节(内存地址,有时:指令地址)被记录到同一个内存。 因此,启用内存跟踪(超过10%或内存访问跟踪)显然会限制可用内存带宽,程序运行速度会变慢。 甚至可以注意到1%的跟踪,但它的影响(开销)较小。

您的CPU E5-2620 v4是Broadwell-EP 14纳米,所以它可能也有一些早期的英特尔PT版本: https ://software.intel.com/zh-cn/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的博客上: http:/ / /halobates.de/blog/p/410 “使用Linux perf和gdb进行英特尔处理器跟踪的备忘单”

PT支持的硬件:Broadwell(第五代核心,至强v4)更多的开销。 没有细粒度的时机。

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

工具开销 :工具涉及将额外的代码动态或静态地注入到目标应用程序中。 附加代码会导致应用程序花费额外的时间来执行原始应用程序…此外,对于多线程应用程序,检测可以修改应用程序的不同线程之间执行的指令的顺序。 因此,具有多线程应用程序的IDS缺乏一定的保真度

缺乏猜测 :仪表只观察在正确的执行路径上执行的指令。 因此,IDS可能无法支持错误路径…

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