内存控制器RPQ/WPQ对Load与NTStore的顺序保障机制问询

问题背景 #

我想理解当**读等待队列（RPQ）与写等待队列（WPQ）**存在显著压力差异时，内存控制器如何维护普通加载（load）与非临时存储（ntstore）之间的程序顺序。

考虑如下执行序列：

load A    // 进入RPQ
ntstore A // 进入WPQ

如果RPQ积压了大量待处理条目（比如20条），而WPQ相对空闲（比如2条），直观来看存储操作可能先于加载完成：

• Load A在RPQ中排在20个其他读操作之后，需要等待很久才能处理
• NTStore A进入近乎空的WPQ，可以快速完成
• 这会违反程序顺序，因为存储操作在其前置的加载操作前完成

测试设计 #

为验证这个假设，我编写了测试程序，核心逻辑：

• 制造高RPQ压力，同时保持WPQ相对空闲
• 对同一地址先发起load再发起ntstore
• 检查load是否读取到ntstore写入的值（若发生则说明顺序违规）
• 通过将RPQ填充地址与测试地址分离，避免缓存影响

核心测试代码片段：

uint64_t val = MAGIC_A;
uint64_t addr = (uint64_t)&memory[test_idx].sentinel;

asm volatile(
    "mov (%1), %%rax\n"      // Load into rax
    "movnti %%rbx, (%1)\n"   // NT Store
    "mov %%rax, %0\n"        // Save loaded value
    : "=r"(val)
    : "r"(addr), "b"(MAGIC_B)
    : "rax", "memory"
);

if (val == MAGIC_B) {  // 若成立则说明存储先于加载完成
    local_violations++;
}

测试结果 #

使用16线程、每个线程处理10M缓存行的条件下运行测试，未发现任何顺序违规。同时通过性能计数器确认达到了预期的队列压力：

$ sudo perf stat -e uncore_imc_0/unc_m_rpq_occupancy/ -e uncore_imc_0/unc_m_rpq_inserts/ -e uncore_imc_0/unc_m_wpq_occupancy/ -e uncore_imc_0/unc_m_wpq_inserts/ -e uncore_imc_3/unc_m_rpq_occupancy/ -e uncore_imc_3/unc_m_rpq_inserts/ -e uncore_imc_3/unc_m_wpq_occupancy/ -e uncore_imc_3/unc_m_wpq_inserts/ sleep 60

 Performance counter stats for 'system wide':

 2,893,410,795,007      uncore_imc_0/unc_m_rpq_occupancy/                                      
     9,443,033,953      uncore_imc_0/unc_m_rpq_inserts/                                       
   574,954,888,344      uncore_imc_0/unc_m_wpq_occupancy/                                      
        32,101,285      uncore_imc_0/unc_m_wpq_inserts/                                       
     1,086,622,871      uncore_imc_3/unc_m_rpq_occupancy/                                      
        38,269,189      uncore_imc_3/unc_m_rpq_inserts/                                       
    76,056,378,805      uncore_imc_3/unc_m_wpq_occupancy/                                      
        31,895,245      uncore_imc_3/unc_m_wpq_inserts/                                       

      60.002128565 seconds time elapsed

计算可得队列深度差异显著：RPQ约306，WPQ约18。

核心疑问 #

在此场景下，内存控制器是如何维护程序顺序的？是什么机制阻止存储操作在其前置加载操作前完成？显然存在超出简单队列调度的顺序保障机制，但我不清楚具体细节。

解答 #

1. 硬件级地址依赖跟踪 #

现代x86内存控制器（比如Intel Uncore IMC）会跟踪RPQ/WPQ中所有条目的地址与程序顺序关系。当检测到WPQ中的NTStore操作与RPQ中更早的Load操作存在同一地址依赖时，会暂停该NTStore的执行，直到前置Load操作完成并返回结果。这种依赖检查是硬件实时执行的，哪怕队列负载差异大，也会强制保障顺序。

2. TSO内存模型的约束 #

NTStore（如movnti）虽然会绕过CPU缓存直接写入内存，但仍需遵守x86的**全存储顺序（TSO）**规则：对于同一地址的Load和Store操作，程序顺序必须得到保障——先执行的Load必须先完成，后执行的Store不能提前覆盖Load要读取的值。内存控制器作为缓存一致性协议的核心参与者，必须强制执行这一规则。

3. 依赖请求的优先级调度 #

即使RPQ积压，内存控制器会优先处理带有后续写依赖的读请求。在测试场景中，Load A属于有后续NTStore依赖的读操作，会被IMC标记为高优先级，跳过部分无关的积压读请求提前执行，确保它在NTStore A之前完成，这也是维持程序顺序的关键调度逻辑。

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