什么是resource_stall.other的含义

Question

什么是resource_stall.other的含义

performanceassemblyx86x86-64

3

威士忌湖 i7-8565U

RESOURCE_STALLS.OTHER 看起来并没有被英特尔文档很好地解释：

计算因其他资源问题而执行受阻的周期数。

我对一个内存复制示例进行了实验，其中包含 6400 次迭代的循环，每次迭代复制 16MiB 的随机生成数据。

基准测试：

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

对于非时间存储，如果发生了资源停顿，则很容易被注意到。因此，我很想知道在Skylake或更新的版本上分析内存限制例程时，RESOURCE_STALLS.OTHER 可能意味着什么。

- St.Antario

我认为这包括RS或ROB已满，例如由于旧的缓存未命中加载，直到数据到达才能退役。当然，还有其他微架构资源，如分支顺序缓冲区，它可以快速恢复错误预测，而无需等待它们到达退役。如果它已满，我认为分支无法进入后端。 - Peter Cordes

1

@PeterCordes 我认为这包含了 RS 或 ROB 已满，例如由于旧的缓存未命中加载导致无法退役，直到数据到达为止。我不确定 ROB 和 RS 是否包含在计数器中，因为它们具有单独的 Umask。我添加了 Intel 文档中提供的所有 Umask。 - St.Antario

1

哦，是的，你更新的数据确实表明这不太可能；ROB_FULL和RS_FULL的计数太低了，无法累加到那个值，因此它们并不占大多数。（假设这些事件确实根据名称/文档测量）。我很惊讶perf没有为更多不同的特定“资源停顿”命名事件。我已经有一段时间没有使用ocperf.py了，也许它知道这些。 - Peter Cordes

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Hadi Brais · Accepted Answer

英特尔仅记录了处理器上两个与资源相关的停顿，即RESOURCE_STALLS.ANY 和 RESOURCE_STALLS.SB。其他事件在 Nehalem/Westmere 上有文档记录，但这并不意味着它们在 Skylake 上能够准确工作。在尝试理解事件计数之前，您必须对其进行验证。至少，我们必须检查RESOURCE_STALLS.ANY是否等于RESOURCE_STALLS.SB和其他未记录事件的总和。看起来它们是相加的。（我记得大约两年前，我曾经处于一种情况下，需要验证 Haswell 上的某些未记录事件，但不幸的是我现在不记得是哪些事件了。）

英特尔手册如下描述了 Skylake 上的 RESOURCE_STALLS.ANY:

计算与资源相关的停顿周期。引起停顿的原因可以是以下内容：
a. 任何 u-arch 结构都已满（LB、SB、RS、ROB、BOB、LM、物理寄存器回收表（PRRT）或物理历史表（PHT）插槽）。
b. 任何 u-arch 结构都已空（例如 INT/SIMD FreeLists）。
c. FPU 控制字（FPCW）、MXCSR 等。
这计算了管道后端从前端阻止 uop 传递的周期。

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

请注意，在旧的微架构上记录性能事件的许多停顿原因现在仅在RESOURCE_STALLS.ANY下被提到，这意味着即使相应的事件没有记录，它们仍然存在。

以下是适用于所有乱序微架构的每个类别的简要说明：

LB: 负载缓冲区保存负载uops和在负载管道上执行的其他uops。这个类别包括特定于LB的停顿原因。当分配器由于任何原因无法为LB分配条目时，将发生LB停顿。
SB: 存储缓冲区保存STA、STD和在存储管道上执行的其他uops。这个类别包括特定于SB的停顿原因。当分配器由于任何原因无法为SB分配条目时，将发生SB停顿。
RS: 这保存所有未完成的uops。RS可能是分布式或统一的，具体取决于微架构。在两种设计中，与RS相关的停顿属于此类别。
ROB: 这保存所有uops以按程序顺序退役。
BOB: 分支顺序缓冲区将寄存器状态与每个推测分支（条件或间接）相关联，以启用快速错误预测恢复。
LM: 负载矩阵跟踪RS中的任何uop与RS中所有负载uops之间的寄存器依赖关系（即，一个uop以输入物理寄存器为参数，该物理寄存器是在程序顺序中先于负载uop的目标）。当存在太多uops依赖于少量负载时，LM可能在LB之前变满。如果有很少的依赖关系但负载较多，则LB可能首先变满。
PRRT: 每次修改物理寄存器的uop退役时，物理寄存器回收表会更新，以指定用于映射相同架构寄存器旧版本的物理寄存器现在可以被回收（因为现在该寄存器具有新的映射）。此结构跟踪已分配的物理寄存器。如果分配器需要分配物理寄存器，则PRRT中必须有一个空闲条目。否则，它将停滞。
PHT: 这跟踪每个架构寄存器到一个或多个物理寄存器的所有当前映射。此结构用于支持快速分支恢复。
INT和SIMD空闲列表: 根据来自PRRT的信息收回寄存器的逻辑。当回收物理寄存器时，它被添加到一个称为空闲列表的结构中，这有效地使其可用于分配。有两个空闲列表，一个用于GP寄存器，另一个用于SIMD寄存器。分配器使用这些列表来了解哪些寄存器是可用的。与物理寄存器可用性有关的停顿属于此类别。
FPCW: 写入浮点控制字的指令，例如FLDCW，可能会使流水线停顿，直到所有早期的uops执行完成。条件取决于微架构和修改的FPCW位（请参见Intel优化手册第3.8.3节）。这些停顿在此处记录。
MXCSR: 这类似于FLDCW。写入MXCSR寄存器的指令，例如LDMXCSR，可能会使管道停顿，直到所有早期的uops执行完成。一个微架构可能会重命名MXCSR，但如果没有，则必须在更改舍入模式之前完成
你调用的事件RESOURCE_STALLS.OTHER包括以下类别：BOB、LM、PRRT、PHT、空闲列表和其他。我认为你在LM上停顿了。尝试将负载更改为写入相同目标寄存器的非内存指令，看看是否会使RESOURCE_STALLS.OTHER变得可以忽略。