CPU获取物理地址后内存写入耗时过长的原因及相关技术疑问

change_pte_range()
[ clear “write”-bit ]
[ defer TLB flushes ]
[ page-fault ]
...
wp_page_copy()
cow_user_page()
[ copy page ]
[ write to old
page ]
...
set_pte_at_notify()

## 问题
为何CPU在获取物理地址后写入内存的耗时会如此之长？我认为仅执行一条store指令的CPU2耗时过长，store指令是否可被中断？我查阅了获取物理地址后访问内存所需的诸多硬件操作（如缓存检查），但这些操作会耗时如此之久吗？

---

## 解答
### 1. 不是单条store指令慢，是触发了硬件竞态与同步流程
CPU2的写操作看起来只是一条store指令，但实际背后是**页表权限与TLB缓存不一致**的竞态：CPU0已经清了页表项（PTE）的写位，但CPU2的TLB还缓存着旧的可写PTE。这时候CPU2的写操作会触发硬件层面的权限校验冲突，不是单纯的内存访问，而是需要同步页表状态、处理TLB失效，整个流程的耗时远超过正常store。

### 2. store指令本身不会被中断，但后续硬件流程会被阻塞
store指令的流水线提交阶段不会被中断，但如果后续遇到**缓存一致性冲突**或**权限不匹配**，硬件会暂停该指令的完成流程，直到冲突解决。这种阻塞表现为“耗时久”，但本质是硬件在等待内存系统的状态同步，而非指令本身被中断。

### 3. 常规缓存操作很快，但竞态引发的连锁反应耗时
正常的缓存检查、store操作都是纳秒级的，但这个场景下有多重叠加的开销：
- CPU2的TLB缓存失效，需要重新走查页表，这个过程涉及内存访问、权限校验，比直接用TLB缓存慢得多；
- CPU1正在执行写时复制（COW）的页复制操作，内存总线、缓存一致性协议（如MESI）会产生大量同步事务，CPU2的写操作会被缓存锁或总线阻塞，直到COW操作完成；
- CPU0延迟刷新TLB的策略，导致CPU2的旧TLB条目没有被及时失效，进一步拉长了状态同步的时间。

### 4. 延迟TLB刷新是核心诱因
CPU0使用了`defer TLB flushes`，也就是修改页表后没有立刻向所有CPU发送TLB失效信号。这种优化能减少TLB shootdown的开销，但也会导致短时间内不同CPU的页表视图不一致，进而触发这类跨CPU的内存访问竞态，最终表现为CPU2的写操作耗时异常。

---

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