现代x86 CPU核心内存事务占用资源与带宽瓶颈问询

一、飞行中内存事务占用的核心资源及瓶颈 #

• 处于飞行状态（未完成）的内存事务主要占用Load队列（LQ）和Store队列（SQ）：Load事务占据LQ条目，Store事务占据SQ条目；未提交的内存操作还会占用**重排序缓冲区（ROB）**条目，但ROB是通用指令缓冲区，并非内存事务专属。
• 通常Load队列/Store队列是最稀缺的资源：ROB容量普遍大于LQ/SQ（如Gracemont的ROB容量为224，远大于LQ的80和SQ的50），要维持足够内存事务并发以隐藏DRAM延迟，LQ/SQ的容量直接决定了可同时在飞的内存请求数量。一旦队列占满，新内存指令无法发射，延迟隐藏效果下降，单核心内存带宽利用率也会被限制。

二、Gracemont架构的“可用并发”验证 #

• Gracemont的LQ/SQ条目按内存操作指令计数，而非数据粒度（16B/64B）：一次64B的Load指令仅占用1个LQ条目，每个周期处理2个128bit（16B）读写是数据通路吞吐量，与队列条目计数无关。
• 理论与实测的差异分析：按DRAM延迟112ns、单核心峰值带宽19.5GB/s计算，饱和总线需约56个64B缓存行并发，LQ（80条）、SQ（50条）理论上可支撑。但实测读写带宽仅10GB/s，对应约70个16B事务并发，实际瓶颈源于：内存请求并非完全连续，LQ需同时容纳缓存命中未提交、DRAM请求的Load指令，加上预取指令占用条目，实际可用DRAM请求并发数被LQ容量限制，无法达到理论峰值。

三、重排序能力与资源瓶颈、软件预取的资源占用 #

• 最大重排序能力下，LQ/SQ会成为瓶颈：重排序内存操作依赖LQ/SQ跟踪未完成的Load/Store，队列满后后续内存指令无法进入流水线，重排序无法继续；ROB因容量更大且覆盖全类型指令，通常不会成为内存带宽瓶颈。
• 核心侧等待内存事务完成的资源：除ROB和Load/Store单元，核心通过LQ/SQ跟踪内存操作的地址与状态，ROB跟踪指令提交状态；内存控制器请求队列、LLC填充队列也会等待DRAM响应，但属于非核心层级资源。
• 软件预取的资源开销：软件预取同样占用LQ条目，但部分架构中预取指令无需进入ROB，仅在Load单元处理；若预取数据提前进入缓存，可减少后续Load指令对LQ的长期占用，整体资源开销略低于普通Load指令。

四、N150（Gracemont核心）PMU实验数据解读 #

• 开启L1 IP预取器后剩余DRAM访问延迟增加：L1 IP预取器会引入额外DRAM请求，导致内存控制器队列拥堵，关键DRAM请求等待时间变长；若预取命中率低，还会占用带宽，拉高有效DRAM请求的延迟。
• 开启双预取器后LLC需求访问量上升：双预取器（如L1 IP预取+L2预取）会预取更多数据，部分无法被L1缓存容纳的数据进入LLC，推高LLC需求访问量；同时无效预取数据占用LLC空间，挤走有用数据，导致后续正常Load请求更多命中LLC，进一步拉高访问量。
• 退休DRAM命中uops与LLC需求miss量差异较大：原因包括：①软件预取指令的DRAM命中不计入“退休DRAM命中uops”（预取指令通常不退休，仅完成数据加载）；②部分LLC miss请求被硬件预取器提前处理，对应Load指令直接命中缓存，不产生DRAM命中uops；③统计粒度差异：LLC需求miss是所有访问LLC未命中的请求，退休DRAM命中uops仅指最终退休的Load指令中直接命中DRAM的部分，中间被预取、缓存填充等操作抵消。

内容的提问来源于stack exchange，提问作者xealits