在Intel x86上，Linux使用事件l1d.replacements来实现其事件。L1-dcache-load-misses事件。

此事件的定义如下：

计算L1D数据线的替换量，包括机会性替换，以及需要停顿替换的替换或需要替换块的替换。

也许天真地，我希望perf使用像这样的东西mem_load_retired.l1_miss，它支持PEBS，并且定义为：

用至少一个在L1高速缓存中未命中的uop计数退休的加载指令。（支持PEBS）

事件值通常不是非常接近，有时会发生巨大变化。例如：

$ocperf stat -e mem_inst_retired.all_loads,l1d.replacement,mem_load_retired.l1_hit,mem_load_retired.l1_miss,mem_load_retired_fb_hit head -c100M /dev/urandom > /dev/null 

 Performance counter stats for 'head -c100M /dev/urandom':

       445,662,315      mem_inst_retired_all_loads                                   
            92,968      l1d_replacement                                             
       443,864,439      mem_load_retired_l1_hit                                     
         1,694,671      mem_load_retired_l1_miss                                    
            28,080      mem_load_retired_fb_hit                                     

与相比，“ L1未命中”的数量多于17 倍。相反，您也可以找到比计数器高得多的示例。mem_load_retired.l1_missl1d.replacementl1d.replacementmem_load_retired

到底在l1d.replacement测量什么，为什么要在内核中选择它，并且它比L1 d缓存未命中更好的代理mem_load_retired.l1_miss？

概括

考虑以下循环：

loop:
movl   $0x1,(%rax)
add    $0x40,%rax
cmp    %rdx,%rax
jne    loop

whererax被初始化为大于 L3 缓存大小的缓冲区的地址。每次迭代都会对下一个缓存行执行存储操作。我希望从 L1D 发送到 L2 的 RFO 请求数量或多或少等于访问的缓存线数量。问题是，即使程序在用户模式下运行，这似乎也只是当我计算内核模式事件时的情况，除非我在下面讨论的一种情况。缓冲区的分配方式似乎无关紧要（.bss、.data 或来自堆）。

细节

我的实验结果如下表所示。所有实验都是在禁用超线程和启用所有硬件预取器的处理器上进行的。

我测试了以下三种情况：

• 没有初始化循环。也就是说，在上面显示的“主”循环之前不会访问缓冲区。我将这种情况称为NoInit. 在这种情况下只有一个循环。
• 首先使用每个缓存线的一条加载指令访问缓冲区。一旦所有的行都被触摸，主循环就会被执行。我将这种情况称为LoadInit. 在这种情况下有两个循环。
• 首先使用每个缓存线的一条存储指令访问缓冲区。一旦所有的行都被触摸，主循环就会被执行。我将这种情况称为StoreInit. 在这种情况下有两个循环。

下表显示了英特尔 CFL 处理器上的结果。这些实验是在 Linux 内核版本 4.4.0 上进行的。

下表显示了英特尔 HSW 处理器上的结果。请注意，HSW 未记录事件L2_RQSTS.PF_HIT、L2_RQSTS.PF_MISS和OFFCORE_REQUESTS.ALL_REQUESTS。这些实验是在 Linux 内核版本 4.15 上进行的。

每个表的第一列包含性能监控事件的名称，其计数显示在其他列中。在列标签中，字母U和 分别K代表用户模式和内核模式事件。对于有两个循环的情况，数字1和2分别用于指代初始化循环和主循环。例如，LoadInit-1K代表LoadInit案例初始化循环的内核模式计数。

表中显示的值按高速缓存行的数量标准化。它们也按以下颜色编码。绿色越深，该值相对于同一表中的所有其他单元格就越大。但是，CFL 表的最后三行和 HSW 表的最后两行未进行颜色编码，因为这些行中的某些值太大。这些行被涂成深灰色，以表明它们不像其他行那样进行颜色编码。

我期望用户模式L2_RQSTS.ALL_RFO事件的数量等于访问的缓存行的数量（即标准化值为 1）。该事件在手册中描述如下：

计算对 L2 缓存的 …

I am attempting to run Alex Ionescu's WinIPT interface in a virtual machine, and having no success. (This is a Windows 10 Pro host running a Windows 10 VM and both are the 18363 update)

I have successfully built and run Intel's driver as well as Alex's toolchain on the host, and processed the trace with ptxed. I have also run Intel's cpuid utility, and verified that the INTEL_PROCESSOR_TRACE feature is active on the host. However, when I run the …

我读到有 AMD 处理器可以让您测量缓存命中和未命中的数量。我想知道 Intel Core Duo 机器上是否也提供这样的功能，或者它们是否尚不支持。

是否可以使用最近的Intel x86芯片上的性能计数器来衡量成功的存储转发操作的数量？

我看到ld_blocks.store_forward哪些措施无法存储转发的事件,但我很清楚是否可以测量成功案例.

我正在尝试使用 RDMSR 和 WRMSR 指令读取 PMC（性能监控计数器）。

在我的具有 Intel i7 6700 CPU (Skylake) 的 Linux 桌面上，我编写了一个简单的驱动程序代码：

static int my_init(void)\n{\n    unsigned int msr;\n    u64 low, high;\n\n    msr = 0x187;\n    low = 0x412e;\n    high = 0x0;\n\n    asm volatile("1: wrmsr\\n"\n            "2:\\n"\n            : : "c" (msr), "a"(low), "d" (high) : "memory");\n\n    msr = 0xC2;\n    asm volatile("1: rdmsr\\n"\n            "2:\\n"\n            : "=a" (low), "=d" (high) : "c" (msr)); \n\n    printk("val: %lu\\n", (low) | ((high) << 32));\n\n    return  0;\n}\n

参考Intel手册（18.2 ARCHITECTURAL PERFORMANCE MONITORING in Intel\xc2\xae …

RESOURCE_STALLS.RSIntel Broadwell 硬件性能事件的描述如下：

此事件对由于保留站 (RS) 中缺少合格条目而导致的停顿周期进行计数。这可能是由于 RS 溢出，或由于 RS 阵列写入端口分配方案导致的 RS 解除分配（每个 RS 条目有两个写入端口而不是四个。因此，无法使用空条目，尽管 RS 并未真正满） . 这计算管道后端阻止来自前端的 uop 传递的周期。

这基本上说有两种情况会发生 RS 停顿事件：

• 当RS 的所有符合条件的条目都被占用并且分配器没有停止时。
• 当因为只有两个写端口而发生“RS 解除分配”时，并且分配器没有停止。

在第一种情况下，“合格”是什么意思？这是否意味着并非所有条目都可以被各种 uop 占用？因为我的理解是，在现代微体系结构中，任何条目都可以被任何类型的 uop 使用。还有什么是 RS 阵列写入端口分配方案，即使并非所有条目都被占用，它如何导致 RS 停顿？这是否意味着 Haswell 中有四个写端口，而现在 Broadwell 中只有两个？即使手册没有明确说明，这两种情况是否适用于 Skylake 或 Haswell？

我正在perf_event_opensyscall之上进行自定义实现。

实施旨在支持各种的PERF_TYPE_HARDWARE，PERF_TYPE_SOFTWARE和PERF_TYPE_HW_CACHE事件上的任何核心特定的线程。

在英特尔® 64 位和 IA-32 架构软件开发人员手册第 3B 卷中，我看到以下用于测试 CPU (Kaby Lake) 的内容：

到目前为止，我的理解是，可以同时监视（理论上）无限的PERF_TYPE_SOFTWARE事件，但同时监视有限的（没有多路复用）PERF_TYPE_HARDWARE和PERF_TYPE_HW_CACHE事件，因为每个事件都是通过 CPU 的 PMU 计数器的有限（如上面的手册中所见）数量来衡量的。

因此，对于启用了超线程的四核 Kaby Lake CPU，我假设最多可以同时监视4 个PERF_TYPE_HARDWARE/PERF_TYPE_HW_CACHE事件（如果仅使用 4 个线程，则最多可监视 8 个）。

对上述假设进行试验后，我发现虽然我最多可以成功监控 4 个PERF_TYPE_HARDWARE事件（8 个线程），但对于PERF_TYPE_HW_CACHE最多只能同时监控 2 个事件的事件，情况并非如此！

我还尝试仅使用 4 个线程，但同时监控的“PERF_TYPE_HARDWARE”事件的上限仍然为 4。禁用超线程也会发生同样的情况！

有人可能会问：为什么需要避免多路复用。首先，实现需要尽可能准确，避免多路复用的潜在盲点，其次，当超过“上限”时，所有事件值都为 0...

PERF_TYPE_HW_CACHE我针对的事件是：

CACHE_LLC_READ(PERF_HW_CACHE_TYPE_ID.PERF_COUNT_HW_CACHE_LL.value  | PERF_HW_CACHE_OP_ID.PERF_COUNT_HW_CACHE_OP_READ.value << 8 | PERF_HW_CACHE_OP_RESULT_ID.PERF_COUNT_HW_CACHE_RESULT_ACCESS.value << 16),
CACHE_LLC_WRITE(PERF_HW_CACHE_TYPE_ID.PERF_COUNT_HW_CACHE_LL.value  | …

我试图了解“perf”输出中“cycles”事件的复用和缩放。

以下是 perf 工具的输出：

 144094.487583      task-clock (msec)         #    1.017 CPUs utilized
  539912613776      instructions              #    1.09  insn per cycle           (83.42%)
  496622866196      cycles                    #    3.447 GHz                      (83.48%)
     340952514      cache-misses              #   10.354 % of all cache refs      (83.32%)
    3292972064      cache-references          #   22.854 M/sec                    (83.26%)
 144081.898558      cpu-clock (msec)          #    1.017 CPUs utilized
       4189372      page-faults               #    0.029 M/sec
             0      major-faults              #    0.000 K/sec
       4189372      minor-faults              #    0.029 M/sec
    8614431755      L1-dcache-load-misses     #    5.52% of all L1-dcache hits    (83.28%)
  156079653667      L1-dcache-loads           # 1083.223 M/sec                    (66.77%)

 141.622640316 seconds …

我正在尝试使用 Intel\xc2\xae 性能计数器监视器 (PCM) 工具测量 NIC 设备的 PCIe 带宽。但是，我无法理解它的输出。

为了测量 PCIe 带宽，我执行了二进制 pcm-iio。该二进制文件有助于测量每个 PCIe 设备的监视器 PCIe 带宽。执行二进制文件后，我得到以下输出。

\n|IIO Stack 2 - PCIe1          |IB write|IB read|OB read|OB write|TLB Miss|VT-d L3 Miss|VT-d CTXT Miss|VT-d Lookup|\n|_____________________________|________|_______|_______|________|________|____________|______________|___________|\n| Part0 (1st x16/x8/x4)       |4498 M  |9003 M |   0   |3256 K  |   0    |   0        |   0          |   0       |\n| Part1 (2nd x4)              |   0    |   0   |   0   |   0    |\n| Part2 (2nd x8/3rd x4)       |   0    |   0   |   0   |   0    |\n| …

我正在针对特定应用程序运行 C++ 基准测试。在此测试中，我在关键部分之前打开性能计数器文件（__NR_perf_event_open syscall），继续该部分，然后在读取指定的指标（指令、周期、分支、缓存未命中等）之后。

我验证了这需要在 sudo 下运行，因为该进程需要 CAP_PERFCOUNT 功能。我还必须验证它是否/proc/sys/kernel/perf_event_paranoid设置为大于 2 的数字，对于带有内核 5.11.0 的 Ubuntu 20.04.3 似乎总是如此，这是我在测试中标准化的操作系统。

此设置适用于我所有的本地计算机。然而，在云中，它仅适用于某些实例，例如 m5zn.6xlarge（Intel Xeon Platinum 8252C）。它不适用于 t3.medium、c3.4xlarge、c5a.8xlarge 等其他版本。

所有这些上的 AMI 都是相同的 ami-09e67e426f25ce0d7。

验证此行为的一种简单方法是运行以下命令：

sudo perf stat /bin/sleep 1

在 m5zn 盒子上我会看到：

 Performance counter stats for '/bin/sleep 1':

          0.54 msec task-clock                #    0.001 CPUs utiliz
             1      context-switches          #    0.002 M/sec
             1      cpu-migrations            #    0.002 M/sec
            75      page-faults               #    0.139 M/sec
       2191485      cycles                    #    4.070 GHz
       1292564      instructions              #    0.59  insn per cyc
        258373      branches …

我有一个Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz( Haswell) 处理器。AFAIK计算DRAM （即）数据读取访问mem_load_uops_retired.l3_miss的数量。顾名思义，计算针对 DRAM 的数据读取次数。因此，这两个事件看起来是等价的（或者至少几乎相同）。但根据以下基准，前一个事件比后者发生的频率要低得多：demandnon-prefetchoffcore_response.demand_data_rd.l3_miss.local_dramdemand

Performance counter stats for '/home/ahmad/Simple Progs/loop':

         1,363      mem_load_uops_retired.l3_miss                                   
         1,543      offcore_response.demand_data_rd.l3_miss.local_dram                                   

   0.000749574 seconds time elapsed

   0.000778000 seconds user
   0.000000000 seconds sys

Performance counter stats for '/opt/evince-3.28.4/bin/evince':

       936,152      mem_load_uops_retired.l3_miss                                   
     1,853,998      offcore_response.demand_data_rd.l3_miss.local_dram                                   

   4.346408203 seconds time elapsed

   1.644826000 seconds user
   0.103411000 seconds sys

Performance counter stats …