x86 SPSC场景下内存子系统拥堵资源及跨架构表现问询

一、核心与非核心内存子系统的拥堵资源 #

当生产者持续写入隔离缓存行的标志变量、消费者持续读取该变量且均处于忙循环时，x86架构的以下资源会出现明显拥堵：

• 核心内部资源：
  • 存储缓冲区（Store Buffer）：生产者的写操作先暂存于此，需等待缓存一致性协议完成无效化（Invalidate）流程后才能提交到L1缓存，频繁的一致性交互会导致缓冲区填满，后续写操作阻塞。
  • 加载端口（Load Port）：消费者的忙循环读操作持续占用加载端口，同时因缓存行状态频繁切换，加载操作需等待一致性响应，进一步加剧端口竞争。
• 非核心内存子系统资源：
  • 互连链路（Mesh/Infinity Fabric）：频繁的缓存一致性消息（Invalidate、Rd、WrAck等）占用大量互连带宽，导致链路饱和。
  • 缓存目录单元：L3缓存的目录需跟踪缓存行的状态和持有核心，频繁的状态切换会导致目录端口拥堵，增加一致性消息的处理延迟。
  • 一致性仲裁器：负责协调多核心间的缓存一致性请求，高频率的请求会使其成为性能瓶颈。

二、Intel Gracemont（E-core）与AMD Zen2架构的性能影响分析 #

1. Intel Gracemont（E-core） #

测试数据显示，当生产者与消费者处于不同E-core时，生产者吞吐量比单线程场景下降约40%，核心原因包括：

• Machine Clears事件激增：machine_clears.memory_ordering事件计数比单线程高出350倍以上。Gracemont的E-core存储缓冲区容量仅为P-core的1/3左右，生产者的写操作因等待Invalidate响应无法及时提交，后续写操作触发存储缓冲区溢出，进而引发机器清除（Machine Clear），强制刷新流水线并重新执行指令，大幅降低性能。
• L1缓存一致性开销：E-core的L1缓存与共享L2缓存的交互延迟较高，消费者读操作触发的Invalidate消息传递耗时更长，进一步延长生产者写操作的等待周期。

2. AMD Zen2 #

当生产者与消费者处于不同CCX（Core Complex）时，生产者性能下降约50%，核心机制包括：

• Infinity Fabric互连竞争：跨CCX的一致性消息需通过Infinity Fabric传递，测试中链路利用率达到85%以上，带宽饱和导致Invalidate响应延迟大幅增加，生产者的存储缓冲区持续处于填满状态，写操作阻塞。
• L3缓存目录压力：Zen2的L3缓存为CCX共享，跨CCX的缓存行状态变更需要更新目录条目，目录端口处理能力不足导致一致性请求排队，加剧存储缓冲区拥堵。
• Store Forwarding失效：消费者的读操作频繁使缓存行变为Invalid状态，生产者后续的写操作无法利用存储转发（Store Forwarding）优化，必须等待缓存行重新获取Exclusive状态才能写入，进一步增加延迟。

三、MESI缓存一致性协议的行为验证 #

上述现象完全符合MESI协议的预期逻辑：

1. 生产者首次写入标志变量时，缓存行进入*Modified（M）*状态，仅生产者持有有效副本。
2. 消费者读取该变量时，向生产者发送Rd请求，生产者将缓存行回写到L3缓存/内存，缓存行状态变为Shared（S），消费者获取副本。
3. 生产者再次写入时，向消费者发送Invalidate请求，消费者将缓存行状态置为Invalid（I），生产者重新获取Exclusive（E）状态后完成写入，缓存行回到M状态。
4. 上述流程在忙循环下持续重复，产生大量一致性交互，直接导致核心内存储缓冲区、互连链路、缓存目录等资源的拥堵。

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