以内部slab为例,管理区 + object总大小+left_over size = 1page,我们做个极端假设,cache为 direct-mapped caches.
1、没有采用slab着色:
页面起始为slab管理区,后接所有object,后接left_over大小空间。如果有两个slab管理区,一个是A,一个是B,那么对于A、B中给出相同的索引时,必定发生conflict miss.
2、采用slab着色:
首先看下代码片段:
struct kmem_cache *kmem_cache_create(const char *name, size_t size, size_t align,
unsigned long flags, void (*ctor)(void*))
{
......
left_over = caculate_slab_order(cachep, size, align, flags);
cachep->colour_off = cache_line_size();
cachep->colour = left_over / cachep->colour_off;
} void kmem_list3_init(struct kmem_list3 *parent)
{
......
parent->colour_next = ;
} int cache_grow(struct kmem_cache *cachep, gfp_t flags, int nodeid, void *objp)
{
.......
l3 = cachep->nodelists[nodeid];
offset = l3->colour_next;
l3->colour_next++;
if(l3->colour_next > cachep->colour)
l3->colour_next = ;
offset *= cachep->colour_off; slabp = alloc_slabmgmt(cachep, objp, offset, .....)
|-->slabp = objp + offset;
|-->offset += cachep->slab_size;
|-->slabp->colour = offset;
|-->slabp->s_mem = objp + offset; //!!!!!!!!!!!!!着色
.......
}
页面起始是一个offset大小的着色量,后接slab管理区,后接所有的object,后接部分剩余空间。那么对于A、B中给出相同的索引时,不会发生conflict miss。问题在于:对于先同的索引这是可以避免的,但是对于不同的索引仍会发生conflict miss,当然对于cache 而言,conflict miss无法避免。在采用着色后,不同的索引也会导致conflict miss。那么我们面对的问题是:对于A、B总给出相同索引的概率有多大,如果概率很大,自然减少了conflit miss,如果给出相同索引的概率较小,则conflict将会趋于平均化。
我不知到A、B中给出相同索引的概率会有多大,但是对于采用着色可以减少conflict miss概率,我持怀疑态度……