您的位置:首页 > 其它

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

2012-10-05 19:47 176 查看


页面上色机制以及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的“上色区”不是一回事。就事论事,胡乱联系定律要不得。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: