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