守株阁

多级缓存与写入 读 miss 只需要把缺失的 block 带到更近的位置。写访问多了一层约束：处理器已经修改了一份副本，下层存储何时看见这个修改？若替换时还有未写回的数据，旧 block 能否直接丢弃？这些问题决定了写策略、dirty bit 和多级缓存的平均访问时间。 本篇的核心问题是：write-through、write-back、write-allocate 和 no-write-allocate 分别改变哪条流量；脏块逐出怎样计入代价；AMAT 的条件概率公式何时能用？核心案例用 1 set × 2 way × 16B 的 write-back/write-allocate cache 追踪五次访问，并补一个 no-write-allocate 写 miss 的反例。证据等级为功能执行加手算。 实验目录为 examples/computer-architecture/cache/。本文附件包括 writeback_amat.json.txt、cache_model.py.txt 和 run_cases.py.txt。 四个写策略词不要混成一个选择 write-throu...

DRAM 与内存控制器 cache miss 以后，请求并不是掉进一个统一的“主存延迟”黑箱。DRAM 有 bank、row buffer、列访问、预充电、刷新和总线仲裁。同样是读取 16B，命中已经打开的 row、换到同一 bank 的另一行、撞上 refresh，等待和服务时间都不同。 本篇的核心问题是：怎样在公开声明的教学时序模型里区分 row hit、row conflict、refresh wait，以及请求等待时间和服务时间？核心案例使用 2 个 bank、64B row、16B block 的小型控制器。证据等级为教学时序模型；参数名参考 gem5 DRAMInterface，但数值是本文题设，不是某款 DRAM 器件。 实验目录为 examples/computer-architecture/cache/。本文附件包括 dram.json.txt、cache_model.py.txt 和 run_cases.py.txt。 地址先映射到 bank 和 row 本文映射函数很小： 123block = address // 16bank = block % 2ro...

隐藏访存延迟 一次 cache miss 的原始延迟可能很长，但程序不一定完全停住。若后面还有独立 miss，非阻塞 cache 可以让多个请求同时在路上；若后面的地址依赖前一次 load 的结果，处理器只能等。预取则尝试在需求访问前把数据带来，但它也会消耗带宽、占 cache line，甚至挤掉后续需要的数据。 本篇的核心问题是：MSHR 怎样让独立 miss 重叠，同一 block 的 miss 怎样合并，依赖链为什么无法重叠；预取命中率之外还要统计什么流量和污染？核心案例使用两个 MSHR entry、10 周期 miss latency 和 next-line prefetch。证据等级为教学时序模型，关键反例由功能断言保护。 实验目录为 examples/computer-architecture/cache/。本文附件包括 mshr_prefetch.json.txt、cache_model.py.txt 和 run_cases.py.txt。 非阻塞 cache 保存“还没回来”的 miss MSHR（Miss Status Holding Register）可以理...

计算机体系结构 20：Sv32、TLB 与权限 核心问题 第 16 到第 19 篇把数据缓存看成“物理地址进入缓存后发生什么”。这一篇补上物理地址之前的一段：一个 load、store 或取指给出的地址通常先是虚拟地址，处理器要用页表把它翻译成物理地址，再把结果交给后续缓存层级。 本篇只回答一个问题：在 RISC-V Sv32 下，TLB miss、page fault 和 data cache miss 为什么是三件不同的事。 这三个词常被混在一起： TLB miss：地址翻译缓存没有现成条目，需要查页表。 page fault：页表项或权限检查不允许这次访问，需要陷入软件处理。 data cache miss：已经得到物理地址后，数据缓存里没有对应数据块。 一个有效翻译可以 TLB miss，但不 page fault。一次 TLB hit 也可以 data cache miss。反过来，page fault 发生时，数据访问还没有资格进入数据缓存模型。 这里的关键模式是先分清“名字缓存”和“数据缓存”。TLB 缓存的是虚拟页到物理页的翻译和权限信息；data cache...

计算机体系结构 21：页故障与映射修改 核心问题 上一篇把地址翻译分成三类结果：TLB miss 后成功、权限失败产生 page fault、翻译成功后再进入数据缓存。本篇继续追踪 page fault 之后发生什么。 一个页故障不是“硬件把问题修好”。硬件报告故障信息，软件决定要不要修复映射、如何更新页表、何时让当前 hart 的旧翻译失效、是否通知其他 hart。本文用一个有限状态轨迹回答三个问题： page fault 报告了什么。 软件补映射后，为什么还要本地 SFENCE.VMA。 多 hart 场景下，为什么本地 fence 不等于远端 shootdown。 异常处理要区分“报告、修复、重试、广播”。硬件只完成报告和控制流转移；页表修改、失效范围和远端协调是软件协议。 边界 一手依据仍然是 RISC-V Privileged Architecture 的 supervisor 规范。2026-09-22 通过可读官方 supervisor 页面核对到 Supervisor-Level ISA 1.13；固定版本 URL 当前不可直接读取，因此正文引用可读官方 UR...

计算机体系结构 22：数据布局与实测解释 核心问题 第 16 到第 19 篇讨论了缓存映射、写策略、DRAM 和并发缺失。第 20、21 篇把虚拟地址翻译补上。到这里，优化问题可以回到程序员最常见的选择：同一份逻辑数据，应该按什么布局放进内存。 本文只回答一个可验收的问题：当模型说 SoA 比 AoS 少读 cache line，或者矩阵分块缩小工作集时，怎样把这个模型结论和本机 wall-clock 计时分开解释。 结论先列出来： AoS/SoA 的 cache-line 模型显示：只读一个字段时，SoA 的模型缺失数更少。 本机计时中，SoA 的中位时间低于 AoS。 本机小参数矩阵乘法中，blocked 版本慢于 plain 版本。 没有性能计数器，所以本文不声称任何真实 L1 miss 数、带宽或能耗。 优化文章要分成三栏：模型预测、程序产物、机器计时。三栏可以互相解释，但不能互相冒充。 边界 本文的一手依据有两类。CS61C cache blocking 材料支持“分块可以改善数据复用，但必须基于声明的缓存模型”。LLVM auto-vectorization 文档...

计算机体系结构 23：缓存一致性与所有权转移 核心问题 第 16 到第 22 篇把单核视角里的 cache、DRAM、TLB、异常和数据布局串起来。多核一出现，同一个地址可能同时存在于多个核心的私有 cache 中。问题不再只是“这次访问命中哪一级”，而是：某个核心写了一个地址后，其他核心还能不能读到旧副本；某个 cache line 的最新值到底来自内存，还是来自另一个核心的脏副本。 缓存一致性解决的是单个地址的副本管理。它不保证所有地址上的操作都像单线程那样排成一个全局序列；跨地址顺序属于内存一致性模型，第 24 篇单独处理。本篇只回答一个可验收的问题：对一个 cache line，如何用失效、共享、独占和脏所有者转移，维持“同一时刻最多一个可写副本”和“读到的值来自最近一次有效写入”。 本文附件： mesi_cases.py.txt mesi_trace.json mesi_summary.txt 证据等级：功能执行。模型是 Python 标准库写成的单 cache line 教学状态机，复跑时会检查 SWMR 断言、失效确认、脏数据来源和最终内存值。它不是商品处理器 ...

计算机体系结构 24：内存一致性模型与 Store Buffering 核心问题 第 23 篇只处理同一个 cache line 的副本一致性。那套规则能阻止两个核心同时写同一地址，也能要求读 miss 找到脏 owner。但是程序通常同时操作多个地址。两个核心各自先写一个地址，再读对方写的地址时，单地址 coherence 没有直接回答“两个读能不能都看到旧值”。 本篇用 Store Buffering 这个 litmus case 切开 coherence 和 memory consistency 的边界： 123初始: x = 0, y = 0T0: x = 1; r0 = yT1: y = 1; r1 = x 问题是结果 r0=0, r1=0 是否可能。顺序一致性模型下不可能；显式 store buffer 教学模型下可能。这个差异说明：每个地址最终都保持一致，并不推出所有地址上的操作都按程序顺序进入一个全局序列。 本文附件： run_cases.py.txt litmus_sc.json litmus_store_buffer.json memory_model_su...

计算机体系结构 25：原子操作与同步边界 核心问题 缓存一致性保证单个地址的副本不会任意分裂；内存一致性模型规定跨地址操作的可见顺序。程序员真正写同步代码时，还要面对第三个问题：一个读改写操作怎样做到不可分割，发布数据时怎样把普通数据写和同步变量写绑定起来。 本篇把原子操作拆成三件事： 原子性：一次 read-modify-write 不能被另一个写切开。 顺序性：release/acquire、fence、aq/rl 等机制约束其他内存操作的可见顺序。 前进性：CAS 或 LR/SC 失败后是否最终能成功，是另一类保证，不能从一次成功轨迹推出。 本文附件： run_cases.py.txt release_acquire.json lrsc_retry.json c11_release_acquire.c run_c11_release_acquire.sh.txt c11_release_acquire_output.txt memory_model_summary.txt 证据等级：功能执行。Python 模型给出事件图和 LR/SC 重试反例；C11 pthrea...

一个进程的临时节点已经被删除，它保存在内存中的“持有锁”状态却可能还在。另一个进程获得了新资格，并不能自动取消旧进程发往数据库的请求。协调服务判断资格，客户端保留对资格的认知，外部资源决定是否接受写入；这三处状态并不会同时变化。 第 18 篇 解释了更新顺序和恢复前缀。本篇进一步区分普通读取、顺序锁和外部 fencing 的保证，使用 Apache ZooKeeper 3.9.6 官方服务与客户端验证三个本机场景。 课程结构仍参考 MIT ZooKeeper 讲义及 Stanford CS244B 日程，没有照搬课程作业实现。 更新有统一顺序，普通读仍可能陈旧 ZooKeeper 的更新进入复制提交链，普通读取可以由连接到的副本本地完成。客户端 FIFO 和同一 session 的进度约束，不等于任意两个 session 之间的实时顺序。 A 的更新完成以后，通过外部通道通知 B，B 再向落后副本读取，仍可能看到旧值。外部通知建立了应用层的先后关系，却没有让 B 所连接的副本自动推进到 A 的更新位置。如果把这段历史当成完整读写寄存器，它不满足线性一致性的实时顺序要求。Hunt ...