TLB Consistency

TLB，translation lookaside buffer，缓存了页表中Virtual Address→Physical Address的映射以及虚拟地址的权限。

然而在发生page swap（page从主存替换到磁盘），page permission 改变（比如读写权限）时，就会发生存在TLB 不一致的问题。如下图所示，开始时Processor X，Y都保存了虚拟页a→物理页A的映射，然而Processor X上执行的进程导致了虚拟页a的内容被Swap到磁盘上，并将映射关系改为虚拟页b→物理页A。

如果此时ProcessorY并不知道，那么Processor在对虚拟页a进行访问时，仍然期望获取到物理页A的内容（实际上已经被替换掉）那么就会存在问题。


常用的做法就是软件层面的TLB Shootdown。

首先，在每个Processor对TLB Miss的页进行访问时，都会更改页表的Access位，如果写脏的话还需要更改Dirty位，操作系统就会记录哪些Core对当前的页进行了访问。当Processor X再要修改页表项时，就需要发送IPI（Internal Processor Interrupt）到已经访问过该页的各个Core上。

这时，接收到中断请求的Core响应中断，flush TLB，发送Ack。Req Core在接受到所有的Core的响应之后，才能更改页表，这就是软件层面维护TLB的操作，详细的流程如下：

1. Initiator Req Core执行修改Page-Table的操作，触发操作系统OS锁定页表项。
2. OS列出过去访问过该页表项的core（Slave Core）。为了实现这个目的，OS需要持续的追踪过去哪些Core访问过该页表项。需要注意的是，我们后面会根据这个列表去发起中断，需要注意的是，可能这个列表中的Core虽然过去访问过该页表项，但是可能PA→VA的映射关系已经用TLB中替换出来了。
3. Initiator Req Core发送IPI到所有的Slave Core，要求它们invalidate TLB中对应的项。与此同时，Initiator Req Core也会invalidate 自己本地的TLB对应项，等待Slave Core发送Ack应答。
4. 所有的Slave Core接收到了IPI中断，然后执行IPI Handler，Invalidate TLB（在执行Handler，即中断程序之前，需要切换protect level，保存当前应用上下文，即常见的进程切换，中断处理中的保存现场操作）。在中断处理程序 invalidate 相关的TLB项之后，发送ack response到Initiator Req Core。
5. 一旦Initiator Req Core接收到了所有的ack信息，它就可以解锁页表项，继续执行修改操作了。

TLB ShootDown的OverHead

• Send IPI Initiator Req Core 统计slave core的集合，并发送IPI。
• Execute Handler Initiator Req Core 和Slave Core执行中断程序，并invalidate 对应的 TLB。
• Wait for Ack Initiator Req Core 需要等待所有Core的Ack Response。
  现在普遍采用的还是TLB ShootDown来维护TLB Consistency，不过已经提出了各种各样的硬件/软件层面的解决方法来解决开销，我们将在后面介绍。