slab着色与cpu硬件高速缓存

     学习LKD的时候，在内存管理一章的slab小节中，对于slab的着色只是一笔带过，并没有详细叙述，只好翻看了很多资料，稍微有了点儿概念，其实关键在于分清所谓的cache（高速缓存，包含多个slab块）和硬件高速缓存的概念。
        slab的设计原理和主体代码不难理解，相应的内存管理效率提升原理也不难理解，问题在于slab着色的原理和用途。我们都知道slab中，相同大小的对象倾向于存放在硬件高速缓存内部相同的cache line中，由此产生的问题是，不同slab中，相同大小的对象很可能最终映射到相同的cache line中，当进行针对这两个对象的读操作时，就出现了两个对象在cache line和RAM之间来回不停切换的现象，更糟糕的是，剩下的一些cache line可能正在无所事事，着色的主要目的就是避免类似的现象发生。
     由于slab是采用空间换时间的方式提高分配效率，因此在slab块中会存在没有用处的字节，我们称作free，另外，由于要和硬件缓存内部的cache line对齐，还存在一个对齐因子的概念，称作aln，能够使用的颜色数据为free / aln+1，free个无用字节被划分为着色域和着色补偿域两部分，分别位于slab块的头和尾，着色域后面紧跟着slab描述符+对象描述符，接下来就是每个对象了，对于对象大小相同的不同slab块，着色域和着色补偿域的大小分别为col x aln和free-col x aln，其中col表示当前slab块的颜色数，当col x aln=free时，代表颜色数已经分配完，新的对象大小相同的slab生成时，col数目从0开始新一轮的循环。这样，就使得对象大小相同的不同slab块中的对象拥有不同的位移量，确保它们不会被映射到硬件缓存内部相同的cache line中。以上是理想情况，当free < aln时，颜色数只有1个，依然无法避免冲突。
     小小总结一下，slab着色功能的高效性是建立在颜色数很多的情况下，但细心的人也会想到，当对象大小相同的slab数目远远超过颜色数时，着色仍然避免不了出现冲突。基于这一点考虑，再加上slab的复杂结构和诸如缓存队列等复杂的层次结构带来的高内存占用，Linux内核小组在2.6.23以及之后的内核版本中，采用slub算法替代了slab算法，按照Linux内核小组人员的说法，slub较slab提升了5%~10%的性能并减少了50%的内核缓存占用，也就是说，不仅仅从时间，而且从空间上都较slab算法有了改善，slub完全兼容slab的接口，内核的其他模块无需修改代码就可以从新的内核缓存分配算法中收益。

 

     同一硬件高速缓存行可以映射 RAM 中多个不同的块，相同大小的对象倾向于存 放在高速缓存内相同的偏移量处。在不同 slab 内具有相同偏移量的对象最终很可能映射到 同一高速缓存行中。而使用 slab 分配器的对象通常是频繁使用的小对象，高速 缓存的硬件可能因此而花费内存周期在同一高速缓存行与 RAM 内存单元之间来来往往的传送两个对象。

 

如下例：假设 cache 行为 32Bytes ， CPU 包含 512 个 cache 行（缓存大小 16K ）。

 

     假设对象 A,B 均为 32B ，且 A 的地址从 0 开始， B 的地址从 16K 开始，则根据组相联或直接相联映射方式 （全相联方式很少使用）， A,B 对象很可能映射到 cache 的第 0 行 ，此时，如果 CPU 交替的访问 A,B 各 50 次，每一次访问 cache 第 0 行都失效，从而需要从内存传送数据。而 slab 着色就是为解决该问题产生的，不同的颜色 代表了不同的起始对象偏移量，对于 B 对象，如果将其位置偏移向右偏移 32B ，则其可能会被映射到 cache 的第 1 行上，这样交替的访问 A,B 各 50 次，只需要 2 次内存访问即可。

     这里的偏移量就代表了 slab 着色中的一种颜色，不同的颜色代表了不同 的偏移量，尽量使得不同的对象的对应到不同的硬件高速缓存行上，以最大限度的提高效率。实际的情况比上面的例子要复杂得多， slab 的着色还要考虑内存对齐等因素，以及 slab内未用字节的大小，只有当未用字节数足够 大时，着色才起作用。