页面上色机制以及CPU高速缓存的工作方式
2012-10-05 19:47
176 查看
页面上色机制以及CPU高速缓存的工作方式
05Apr 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的“上色区”不是一回事。就事论事,胡乱联系定律要不得。
相关文章推荐
- linux内核机制 CPU、内存、硬盘的关系物理内存以及虚拟内存的关系【未完成】
- ASP.NET页面运行机制以及请求处理流程
- ASP.NET页面运行机制以及请求处理流程
- 8086架构的CPU的内存访问机制以及内存对齐(memory alignment)
- ASP.NET页面运行机制以及请求处理流程
- ASP.NET页面运行机制以及请求处理流程
- ASP.NET页面运行机制以及请求处理流程
- 从一道试题分析请求分页的虚拟内存机制、高速缓存的cache机制以及两者之间的区别联系
- ASP.NET页面运行机制以及请求处理流程
- Java和C++访问权限以及多态机制的一些区别
- Response.Write()语句造成页面布局改变以及字体变化的解决办法
- Java和C++的区别以及Java的垃圾回收机制
- [转]Android上GTalk以及Push机制的XMPP数据选择使用protobuf格式而非XML格式
- QuickPart的部署以及用QuickPart包装用户控件到Moss页面的实例
- java之学习笔记(13)-------------数组学习以及循环机制中for each讲解
- 利用php的ob缓存机制实现页面静态化
- 浏览器渲染页面过程描述,DOM编程技巧以及重排和重绘
- valuestack,stackContext,ActionContext.之间的关系以及action的数据在页面中取得的方法
- MySQL服务器性能(通过Sysbench测试cpu、io、内存以及mysql服务等)
- jsf页面导航以及bean对象的注册