RESOURCE_STALLS.RSIntel Broadwell 的硬件性能事件描述如下：
此事件计算由于保留站 (RS) 中没有符合条件的条目而导致的停顿周期。这可能是由于 RS 溢出，或者由于 RS 数组写入端口分配方案而导致的 RS 释放（每个 RS 条目有两个写入端口而不是四个。因此，尽管 RS 并未真正满，但无法使用空条目） . 这会计算管道后端阻止来自前端的 uop 传递的周期。
这基本上说有两种情况会发生 RS 停顿事件：
在第一种情况下，“合格”是什么意思？这是否意味着并非所有条目都可以被各种微指令占用？因为我的理解是，在现代微架构中，任何条目都可以被任何类型的 uop 使用。还有什么是 RS 阵列写端口分配方案，即使不是所有条目都被占用，它如何导致 RS 停顿？这是否意味着 Haswell 中有四个写入端口，但现在 Broadwell 中只有两个？即使手册没有明确说明，这两种情况是否适用于 Skylake 或 Haswell？
是的，可以RESOURCE_STALLS在 RS 完全充满之前指示完全的 RS。
随着 RS 变满，将新微指令分配到 RS 中变得不太理想，直到某个时候它可能完全停止，即使仍然有一些条目。
此外，并非所有 RS 条目都可用于所有指令。例如，在 Haswell 上，我观察到 60 个 RS 条目中只有 30-32 个可用于加载：例如，这些条目可能是特殊的，因为它们支持 uop 重放。在 Skylake 上，情况有所不同：整个 RS 不适用于任何类型的指令：相反，“97 条目”RS 实际上由用于 ALU 操作的 64 条目 RS 和用于加载操作的 33 条目 RS 组成. 因此，RS(es) 的全部 97 个条目很少会被填满，除非出于某种巧合，两者都在完全相同的时刻填满。
事件RESOURCE_STALLS.RS(umask 0x4) 仅在 RS 的“ALU”部分已满（或已满以至于操作无法分配）时触发。对于负载 RS（与 Haswell 中的 ALU RS 重叠但不与 Skylake 重叠），相应的事件具有 umask 0x40。您可以将其与perfas一起使用'cpu/event=0xa2,umask=0x40,name=resource_stalls_memrs_full/。尽管 Skylake 没有记录这些事件，但它们似乎工作正常（尽管通过 umasks 的事件与0x10Sandy 0x80Bridge 上记录的事件非常不同。
未来的英特尔芯片可能会有更细粒度的预约站。
我编写了一个程序，可用于探索英特尔处理器中未记录的 RS 限制，希望我能够最终回答这个问题。基本思想是在循环中分配和执行特定的微指令序列之前确保 RS 完全为空。RESOURCE_STALLS.RS可用于确定该序列是否已达到 RS 本身的限制。例如，如果RESOURCE_STALLS.RS每次迭代为 1，则分配器必须停止一个周期才能为序列中的所有微指令分配 RS 条目。如果RESOURCE_STALLS.RS每次迭代远小于 1，那么它基本上不必停止，因此我们知道我们没有遇到任何 RS 限制。
我已经尝试过一系列相关ADD指令、一系列相关 BSWAP 指令、一系列相关加载指令到同一位置、一系列后向或前向无条件跳转指令以及一系列存储指令到同一位置。以下两张图显示了add针对不同目标 RS 占用的指令序列的结果（微指令序列同时需要和占用的最大 RS 条目数）。每次迭代都会显示所有值。
下图显示，RESOURCE_STALLS.RS当 RS 占用率为 50 时，每次迭代至少（或接近）1 个循环。虽然不是很明显，RESOURCE_STALLS.RS但当 RS 占用率超过 43 时变得大于零，但仅在 RS 占用率超过 1 时占用率超过 49。换句话说，我只能同时使用 60 个（在 Haswell 中）中的 49 个 RS 条目，而没有 RS 档位。之后，RESOURCE_STALLS.RS序列中每增加一个 uop，平均增加 1，这与分配器的突发行为以及每个ADDuop 可以在每个周期完成的事实一致（每个 uop 仅占用 1 个周期的 RS 条目）。cycles每增加一个 uop，平均增加 2.3。每个额外的 uop 大于 1，因为 ROB 上还有额外的档位，原因与adduops 无关，但这些都可以，因为它们不会影响RESOURCE_STALLS.RS.
下图显示了cycles每次RESOURCE_STALLS.RS迭代的变化。它说明了执行时间和 RS 停顿之间的强相关性。
当目标 RS 占用率在 44-49 之间时，RESOURCE_STALLS.RS它非常小，但仍然不是真正的零。我还注意到，不同微指令呈现给分配器的确切顺序会稍微影响可以达到的 RS 占用率。我认为这是英特尔手册中提到的 RS 阵列写入端口分配方案的效果。
那么其他 11 个 RS 条目是怎么回事（Haswell 的 RS 应该有 60 个条目）？RESOURCE_STALLS.ANY表演活动是回答问题的关键。我更新了用于执行这些实验以测试不同类型负载的代码：
loadspec。loadnonspec。loadspecreplay。我对指令采用了相同的方法ADD，但这次我们需要观察RESOURCE_STALLS.ANY而不是RESOURCE_STALLS.RS（实际上不会捕获由于负载导致的 RS 停顿）。下图显示了cycles每次RESOURCE_STALLS.ANY迭代的变化。第一个尖峰表示目标 RS 占用率已超过该类型 uop 的可用 RS 条目。我们可以清楚地看到，对于这个loadspec案例，load uops 正好有 11 个 RS 条目！当目标 RS 占用率超过 11 时，一个 RS 条目平均需要 3.75 个周期才能空闲到下一个加载 uop。这意味着微指令在完成时从 RS 中释放，而不是在它们被分派时。这也解释了 uop replay 的工作原理。峰值loadspecreplay出现在 RS 占用 6 处。loadnonspec发生在 RS 占用 9 处。正如您稍后将看到的，这 11 个条目并非专用于负载。负载使用的 11 个条目中的一些可能在ADDuops 使用的 49 个条目中。
我还为商店开发了两个测试用例：一个达到了存储缓冲区的限制，另一个达到了 RS 的限制。上图显示了前一种情况。请注意，商店需要 RS 中的两个条目，因此目标 RS 占用为奇数的情况与之前的偶数 RS 占用相同（变化为零）。该图显示，RS 中最多可以同时存在 44/2 = 22 个存储。（我用来制作 store graph 的代码有一个 bug，会导致实现的 RS 占用率大于实际值。修复后，结果显示 RS 中最多可以同时存在 20 个 store。）存储地址或存储数据uop 占用的条目可以在一个周期内释放。英特尔说 Haswell 的存储缓冲区有 42 个条目，但我无法同时使用所有这些条目。我'
跳跃序列没有造成任何停顿。我认为这可以解释如下：跳转微指令释放它在一个周期内占用的 RS 条目，并且分配器在分配跳转微指令时不会以突发方式运行。也就是说，每个周期都有一个 RS 条目空闲，分配器将只分配一个跳转 uop 而不会停止。因此，无论有多少跳转 uops，我们最终都不会停滞不前。这与添加微指令相反，其中突发分配器行为使其停止，直到所需数量的 RS 条目变为空闲（4 个条目），即使添加微指令的延迟也是一个周期。尽快分配跳转是有道理的，以便可以尽早检测到任何错误预测。因此，如果分配器看到一个跳转，并且 RS 中有足够的空间供它使用，但它的 4 uop 组中没有稍后的 uop，那么它仍然会分配它。否则，它可能不得不等待可能会显着延迟错误预测检测的许多周期。这可能非常昂贵
有没有一条指令可以同时占用RS的60个条目？是的，一个例子是BSWAP。它的两个微指令需要两个 RS 条目，我可以清楚地看到RESOURCE_STALLS.RS，它的微指令可以同时使用 RS 的所有 60 个条目（假设我的计算对于使用该指令的 RS 占用率如何增长是正确的）。这证明 RS 中确实有 60 个条目。但是对于它们的使用方式存在一些限制，我们仍然不太了解。