Cache 为什么是物理地址映射？ 及与TLB的关系？

转载：http://blog.sina.com.cn/s/blog_488c30d301013kua.html

cache是体系结构中很重要的一个设计，也是有关存储体系中的一个重要环节，考虑到现实的应用中，由于开发了虚拟地址这个概念，即每个进程都可以拥有一个完整的虚拟地址空间，这样，CPU在执行两道不同的进程，而进程的指令访问都是基于虚拟地址的，因此，可能出现的情况是：进程A在被执行一段时间后，由于进程调度，被切换出去，需要执行进程B，而进程A的PCA（进程A的取指地址指针）所指向的一段代码正在cache中，而进程B的PCB，由于是虚拟地址概念，有可能PCB=PCA（经过虚实地址转换后，物理PCB绝对不会等于物理PCA），如果在cache中利用PCB去访问PCA，则会导致cache hit，但这个时候cache hit其实是错误的，因为cache中存放的是进程A的指令。

为此，针对上述问题，尤其是在虚拟地址这个概念出现后，需要考虑cache的虚拟地址问题。如果我们的系统不支持虚拟地址，也就是没有MMU的系统，则可以不考虑这个问题——因为每个程序，进而每道进程的地址空间都是物理地址空间是不一样的，不会产生上面的冲突情况。


为了解决上面的问题，产生了如下的几种处理cache的方法，我好像没有在张和胡的书上有看到这部分的介绍啊，奇怪了。

物理地址访问的cache结构
在这种模式下，cache访问时使用的就是物理地址，也就是虚拟地址经过TLB转换后的物理地址。在这种情况下，流水线在使用PC访问cache的时候，首先要利用TLB进行虚实地址转换，然后访问cache，这个时候可以理解为TLB其实是处在cache和流水线之间。这时候，每条指令的执行都需要进行一次虚实地址转换，即查找TLB，然后再访问cache。
由于页表所表示的一个页的空间比较大，例如有4KB或者更大，因此，在一般情况下，TLB的失效率不会很高，但带来的问题就是：每次访问cache都要访问一次TLB，而如果TLB失效，流水线的性能损失非常大，因此TLB一般是存储在外部存储器中。而如果一段指令一直存储在cache中，流水线还是要每次访问TLB才能访问到cache，就感觉会：多此一举。而事实是带来流水线一个流水级的性能损失。


所以用物理地址访问cache的方法是不被挑剔的人类所接受的。
那么，就采用虚拟地址访问cache的方法
这种方法从逻辑上看很简单：流水线是利用虚拟PC访问cache，而cache支持虚拟地址访问，所以这样最直接，但我们更深入想想，这样会带来不少的问题：
1）如果两段进程的虚拟PC正好相同，则会出现虚地址访问cache冲突的情况；
2）现代操作系统注重安全保护观念，而安全保护的方法是基于进程描述符ID，体现到了内存页表上，因此操作系统的保护概念是需要依赖于页表的安全，而如果cache直接用虚拟地址访问，就绕过了页表机制，从而使用流水线中指令的执行不再存在保护；
3）现代操作系统允许有多个虚拟页面空间映射到同一个物理地址页面空间，因此，如果纯粹是虚拟地址访问，就可能出现读写不一致的情况，就好像多处理器的cache一致性问题一样，如果希望利用其他协议在流水线和cache之间解决这个问题，则性能浪费太大了；
4）读写外部设备的问题：现在外部IO设备的地址映射一般是物理地址映射；而我们有TLB把虚拟地址映射为物理地址，但是在读写外部IO设备时，我们是没有机制把物理地址映射为虚拟地址的。


针对上面出现的情况，大伙想出了一个方法即虚拟地址访问cache，物理地址比较Tag。这种模式其实是利用了页表的虚拟地址和物理地址其实在地位是相同的，不同的是高位映射。
在说明这种方法之前，要看看物理地址cache方式的节拍：

• 节拍-1：利用虚拟地址访问TLB，进行虚实地址转换，假设TLB命中（概率很大），需要一个时钟周期；
• 节拍-2：利用得到的物理地址访问cache，取出cache行的TAG信息和data信息；假设cache命中，需要一个时钟周期；
• 节拍-3：基于物理地址，对TAG信息进行比较以及选择合适的cache data；还是需要一个时钟周期。

因此，这种模式下，如果TLB和cache都命中，需要3个时钟周期得到需要的指令；
而虚实结合的cache访问方式，其模式如下：

• 节拍-1：利用虚拟地址访问TLB，进行虚实地址转换；同时在这个周期中，利用虚拟地址的低位访问cache，取出cache中存储的TAG信息和data信息，但注意，这个时候的TAG信息其实对应的是物理地址的TAG；
• 节拍-2：假设TLB和cache都命中，则利用上个节拍得到的物理地址进行TAG比较，并选择合适的cache data数据。

这种模式下，仅需要2个时钟周期就能得到所需要的cache数据。