resource_stall.other可能意味着什么

Question

Whiskey Lake i7-8565U

RESOURCE_STALLS.OTHER看起来不像是英特尔文档的充分解释：

计算由于其他原因导致执行停止的周期数资源问题。

[我在一个由16MiB个迭代组成的循环中，对6400个随机生成的数据的内存副本的一个示例进行了实验。

---

基线：

avx_memcpy_baseline:
    shr rdx, 0x3
    xor rcx, rcx
avx_memcpy_baseline_loop:
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_memcpy_baseline_loop
    ret

基准计数器：

   823 292 269      resource_stalls.any
       181 045      r02a2 #LOAD
   831 370 403      r04a2 #RS_FULL
        49 659      resource_stalls.sb
       130 100      r10a2 #ROB_FULL
        63 386      r20a2 #FPCW
     2 151 516      r40a2 #MSCXR
         4 222      r80a2 #OTHER  

WB商店：

avx_memcpy_forward_llss:
    shr rdx, 0x3
    xor rcx, rcx
avx_memcpy_forward_loop_llss:
    vmovdqa ymm0, [rsi + 8*rcx]
    vmovdqa ymm1, [rsi + 8*rcx + 0x20]
    vmovdqa [rdi + rcx*8], ymm0
    vmovdqa [rdi + rcx*8 + 0x20], ymm1
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_memcpy_forward_loop_llss
    ret

WB存储计数器：

27 089 245 473      resource_stalls.any
     4 873 836      r02a2  #LOAD                                                                                                                                          
    14 099 696      r04a2  #RS_FULL                                                                                                                                          
24 130 341 296      resource_stalls.sb                                                                                                                                                               
     5 790 969      r10a2  #ROB_FULL                                                                                                                                               
       375 032     r20a2   #FPCW                                                                                                                                                      
     3 395 592      r40a2  #MXCSR
 4 899 892 032      r80a2   #resource_stalls.other 14% of RESOURCE_STALL.ANY

NT个商店：

avx_nt_memcpy_forward_llss:
    shr rdx, 0x3
    xor rcx, rcx
avx_nt_memcpy_forward_loop_llss:
    vmovdqa ymm0, [rsi + 8*rcx]
    vmovdqa ymm1, [rsi + 8*rcx + 0x20]
    vmovntdq [rdi + rcx*8], ymm0
    vmovntdq [rdi + rcx*8 + 0x20], ymm1
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_nt_memcpy_forward_loop_llss
    ret

NT存储计数器：

18 121 917 993      resource_stalls.any
     2 211 195      r02a2 #LOAD
     5 588 784      r04a2 #RS_FULL
12 061 475 989      resource_stalls.sb
     3 156 129      r10a2 #ROB_FULL
       165 967     r20a2  #FPCW
     2 152 595      r40a2  #MXCSR                                                       
 6 730 668 837      r80a2 #resource_stalls.other 33% of RESOURCE_STALLS.ANY   

---

[在非临时性商店中，它占用了所有资源停顿的1/3，这是非常值得注意的，因此，我很想知道在Skylake或更高版本上对内存绑定例程进行概要分析时，RESOURCE_STALLS.OTHER的含义。

Answer 1

Intel仅记录了处理器上两个与资源相关的停顿，即RESOURCE_STALLS.ANY和RESOURCE_STALLS.SB。其他事件记录在Nehalem / Westmere上，但这并不意味着它们可以在Skylake上正常工作。您必须先验证它们，然后再尝试从事件计数中弄清楚。至少，我们必须检查RESOURCE_STALLS.ANY是否等于RESOURCE_STALLS.SB与其他未记录事件的和。看起来他们确实加起来了。 （IIRC，大约两年前，我处于不得不验证Haswell上某些未记录事件的情况，但不幸的是，现在我不记得是哪个事件。）

Intel手册在Skylake上对RESOURCE_STALLS.ANY的描述如下：

计算与资源有关的停顿周期。停顿原因可以是如下：一种。 any u-arch结构已满（LB，SB，RS，ROB，BOB，LM，物理寄存器回收表（PRRT），或物理历史记录表（PHT）插槽）。b。 any u-arch结构为空（如INT / SIMD FreeLists）。C。 FPU控制字（FPCW），MXCSR等。这算是周期管道后端阻止了前端的uop交付。

此描述提供了与资源相关的停顿的类别的部分列表，而不是特定的停顿原因。例如，RS类别包括许多特定于RS的停顿原因。英特尔大多数乱序的微体系结构中都存在这些问题，但是具体的停顿原因在不同的微体系结构上可能有很大的不同。就其对性能的影响而言，每个类别的相对重要性也取决于微体系结构。从分析的角度来看，这种分类很方便。

[注意，现在在RESOURCE_STALLS.ANY下简单地提到了在旧的微体系结构上记录了性能事件的许多停顿原因，这意味着即使没有记录相应的事件，它们仍然存在。

这里是适用于所有乱序微体系结构的每个类别的简要描述：

• LB：负载缓冲区保存负载uops和在负载管道上执行的其他uops。此类别包括特定于LB的停转原因。当分配器由于任何原因无法分配LB条目时，就会发生LB停顿。
• SB：存储缓冲区保存在存储管道上执行的STA，STD和其他块。此类别包括特定于SB的停转原因。当分配器由于任何原因无法分配SB条目时，就会发生SB停顿。
• RS：这包含所有未完成的操作。 RS可以是分布式的，也可以是统一的，具体取决于微体系结构。在这两种设计中，与RS相关的档位都属于此类。
• ROB：这将保留所有uops以便按程序顺序将其退休。
• BOB：分支顺序缓冲区将寄存器状态与每个推测的分支（有条件的或间接的）相关联，以实现快速的错误预测恢复。
• LM：加载矩阵跟踪RS中任何uop与RS中所有加载uop之间的寄存器相关性（即，一个uop将物理寄存器作为输入，该物理寄存器是按程序顺序位于前面的加载uop的目的地）。当过多的微指令取决于少量负载时，LM可能会在LB之前变满。如果依赖项很少但负载过多，则LB可能会先变满。
• PRRT：每次修改物理寄存器退出的uop时，都会更新物理寄存器回收表，以指定现在可以回收用于映射同一体系结构寄存器的旧版本的物理寄存器（因为现在有一个该寄存器的新映射）。该结构跟踪分配的物理寄存器。如果分配器要求分配物理寄存器，则PRRT中必须有一个空闲条目。否则，它将停止。
• PHT：这将跟踪每个体系结构寄存器到一个或多个物理寄存器的所有当前映射。此结构用于支持快速分支恢复。
• INT和SIMD可用列表：有一些逻辑可以根据PRRT的信息回收寄存器。回收物理寄存器后，会将其添加到称为“空闲列表”的结构中，该结构有效地释放了分配空间。有两个空闲列表，一个用于GP寄存器，另一个用于SIMD寄存器。分配器使用这些列表来了解哪些寄存器是空闲的。与物理寄存器的可用性相关的停顿属于此类别。
• FPCW：写入浮点控制字的指令，例如FLDCW，可能会使流水线停滞，直到所有较早的指令完成执行。条件取决于所修改的微体系结构和FPCW位（请参阅英特尔优化手册的3.8.3节）。这些摊位在这里计算。
• MXCSR：这类似于FLDCW。写入MXCSR寄存器的指令（例如LDMXCSR）可能会使流水线停滞，直到所有较早的指令完成执行。一个微体系结构可以重命名MXCSR，但是，如果不这样，它就必须在更改舍入模式之前完成较早的数学指令。
• 其他：还有许多其他停滞原因不属于上述任何类别。英特尔已决定不提及它们。

您称为RESOURCE_STALLS.OTHER的事件包括以下类别：BOB，LM，PRRT，PHT，空闲列表和其他。我认为您正在停滞不前。尝试将负载更改为写入相同目标寄存器的非内存指令，然后查看RESOURCE_STALLS.OTHER是否可以忽略。