页面上色机制以及CPU高速缓存的工作方式

页面上色机制以及CPU高速缓存的工作方式

05 Apr 2011 \ fleuria ->

摘译自：Design elements of the FreeBSD VM system 作者： Matthew Dillon 翻译：fleurer

---

Q: Finally, in the page coloring section, it might help to have a little more description of what you mean here. I did not quite follow it.

A: 对L1高速缓存的工作方式有了解不？我解释一下。假如一台机器有16MB的物理内存，同时只有128kb的L1高速缓存。它通常也就对应了一整块128k的内存。你要先访问了地址0，再接着访问地址128k的话，也就把刚才访问地址0留下的缓存都刷没了！

这样就把问题简化多了。刚才我们提到的缓存方式称为“direct mapped”的高速缓存，而现代的缓存技术多数采用2-way-set-associative或者4-way-set-associative技术。所谓"N-way-set-associative"，也就是允许你缓存N块不同的内存区域而不至于将原先的缓存完全覆盖。但只有N个，不多。

假如我有个4-way set associative的高速缓存，先访问地址0，然后访问地址128k,256k,384k再回来访问地址0仍然可以命中高速缓存。不过再访问512k，前面留下的四块缓存之一就得刷掉。

这很重要...尤其是CPU的内存访问几乎都是经过L1高速缓存，作为CPU周期的一部分。要是缓存命中失败，就不得不访问L2缓存甚至访问内存，CPU也就只能坐着眼巴巴干等这几百个指令时间的内存访问了。跟现代处理器的速度相比，内存访问无疑慢的很。

好，回正题，页面上色：现代的高速缓存都是物理缓存。即针对物理地址的缓存，而不是针对虚拟地址。这一来高速缓存即可无视进程的上下文切换，减少不必要的缓存失效。（译者注：如果是针对虚拟地址的缓存，那么每次上下文切换之后地址的映射即全部改变，所有的缓存也就都无效了。进程切换十分频繁，这样显然不靠谱。）

但是，在Unix世界里虚拟地址才是王道。我们写的任何程序都在虚拟地址空间中执行，连续的虚拟页面对应的物理页面不必连续。实际上，在虚拟地址空间里隔着十万八千里的两个虚拟页面，其对应的两个物理页面没准还是靠着的。

程序通常假定相邻的两个页面是理想地缓存的。也就是说你分别访问两个页面中的对象，不会影响到彼此的缓存(译者注：这两个对象在高速缓存中的位置相互重合)。但是这样，(目前看来)只有连续的虚拟页面对应的物理页面也是连续的才有可能。

都是随机申请来的物理页面，靠它们填出来的虚拟地址空间就可能会对缓存不友好。这就是页面上色所做的，为连续的虚拟页面提供“貌似”连续的物理页面。这样在高速缓存看来，就抹平了虚拟地址与物理地址的区别。

留意前面我说是“貌似”的连续。对一个128kb大小direct mapped的高速缓存来说，物理地址0与物理地址128k是没有区别的。因此两个连续虚拟页面对应的物理页面若分别为128k与132k(页面大小4k的话)，在高速缓存看来就是连续的。所以说，页面上色机制带来的不是真正连续的物理页面，而是“在高速缓存看来”连续的物理页面。

译者注：

---

• 文里没说，高速缓存对系统程序员是完全透明的，没有任何接口。做优化只能是迁就着它的性子。
• 文里也没说，L1高速缓存也是按照地址存东西的。L1高速缓存地址 = 物理页面地址 % L1高速缓存大小。单位是缓存行(cache line)，行可以构成组(set)，组中的行没有顺序。
• 个人感觉不一定说不连续的物理页面就一定有问题，而是有个概率。假如是直接映射的高速缓存，有两个连续的虚拟页面1和2，其对应的物理页面地址正好同余(比如132k和260k, 132k%128k==260k%128k))，它们在高速缓存中就可能会占据同一个位置，访问页面1，这块高速缓存就是页面1的内容，访问页面2，这块高速缓存就是页面2的内容。先访问页面1再访问页面2再访问页面1，这样高速缓存就miss了两次。再加上引用局部性原理，这样一来一去是很折腾的。回过来想想，问题就出在“两个连续的虚拟页面对应的物理页面正好同余”这里，随机分配物理页面的话，这样的概率恐怕也不见得多高。不过回避开总是好的(通过页面上色)。
• N-way-set-associative式高速缓存的话，发生不利情况的概率就更小了。但这样会使高速缓存的设计更加复杂。
• 所谓“颜色”差不多就是一个余数，物理页面地址 % L1高速缓存大小，每个“颜色”对应一个空闲物理页面的freelist。没有页面上色之前，只需要一个freelist。
• 增加了内存管理的难度，得到的好处是抹平了(在高速缓存看来)虚拟地址与物理地址的区别。
• Linux喜欢连续的物理页面，因此似乎没必要页面上色机制。
• 虽说都跟高速缓存有关，这里的“页面上色”这跟slab的“上色区”不是一回事。就事论事，胡乱联系定律要不得。