这确实是个反直觉的现象——按经典缓存理论，只读操作时Write-Through（WT）和Write-Back（WB）的缓存行为应该几乎一致：命中读缓存，缺失则填充缓存。但你的测试结果差了两个数量级，肯定是实际硬件/系统层面的细节没覆盖到。我来帮你梳理几个最优先级的排查方向：

1. 确认页表PWT标志的实际生效状态 #

你提到用内核模块设置页表的PWT位，但这里很容易出现隐性bug：

• 可以通过解析/proc/self/pagemap文件来验证目标内存区域的页表项是否真的设置了PWT（页表项的第3位），同时要确保PCD位（第4位）是0——如果PCD被误设为1，该区域会直接禁用缓存，性能暴跌是必然的。
• 也可以用调试工具（比如GDB结合内核符号）查看CR3指向的页表结构，直接确认目标页的属性位。很多自定义内核模块的标志逻辑会忽略页表项的其他关联位，导致实际缓存属性不符合预期。

2. 验证MAP_POPULATE的预填充行为差异 #

MAP_POPULATE会触发内核预分配物理页并建立页表映射，但WB和WT的预填充路径可能存在差异：

• WB模式下，预填充可能会直接将页加载到各级缓存中；但WT模式下，内核可能仅完成页表映射，没有触发缓存填充操作。这会导致后续第一次只读操作全部是冷缓存缺失，直接走内存读取。
• 你可以做个对比测试：去掉MAP_POPULATE，先手动用memset(ptr, 0, SIZE)写一遍整个区域（写操作会强制触发缓存填充，无论WB/WT），再执行只读计时。如果此时性能差异大幅缩小，就说明预填充的行为差异是核心原因。

3. 排查x86硬件的WT缓存特性细节 #

x86的WT缓存并非完全和WB对称，存在一些容易忽略的硬件特性：

• 预取器行为差异：部分CPU的预取器对WT缓存区域的预取策略更保守甚至禁用，而WB区域会积极预取后续缓存行。顺序读取时，WB能通过预取大幅减少缓存缺失，而WT则频繁触发内存访问。你可以改成随机读取测试（比如用随机索引访问ptr），如果差异明显缩小，就说明预取是关键因素。
• 一致性总线事务：WT缓存行在填充后，硬件可能会额外发起总线一致性检查（即使是只读操作），而WB缓存行仅在修改时才触发一致性操作。额外的总线事务会大幅增加延迟。

4. 确认RDTSC计时的准确性 #

RDTSC的计时很容易受到CPU乱序执行、频率缩放的影响：

• 你的RDTSC_START()和RDTSC_STOP()宏是否做了指令序列化？比如在RDTSC前插入lfence或cpuid指令，确保前面的所有指令都执行完毕，后面的指令还未开始。如果没有序列化，WB测试可能因为乱序执行提前结束计时，而WT测试因为等待内存，乱序影响小，导致计时被放大。
• 建议用clock_gettime(CLOCK_MONOTONIC, ...)做交叉验证，对比两种计时方式的结果是否一致。

5. 检查MTRR/PAT的内存类型配置 #

x86系统除了页表的PWT/PCD位，还有MTRR（内存类型范围寄存器）和PAT（页属性表）会影响内存区域的缓存行为：

• 如果MTRR将目标区域误配置为Uncached（UC）或Write-Combining（WC），WT模式下的性能会直接暴跌。可以用x86info或cpuid工具查看MTRR和PAT的配置，确认目标区域的内存类型确实是Write-Through，而非其他类型。

代码优化建议 #

另外，你的测试代码可以做几个小调整，减少干扰因素：

• 增加warm-up循环：在计时前先跑一遍相同的读取循环，让缓存提前预热，避免冷启动的影响。
• 确保循环变量和读取结果不会被编译器优化掉：可以在循环后添加volatile修饰a，或者把a的值打印出来（即使是debug输出），防止编译器将整个读取循环优化为空操作。

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