Linux内存分配slub的几个疑问

对于SLUB不熟的同学可以先跳过了,涉及的东西比较细致。

简单来说SLUB的结构是N(CPU数)个kmem_cache_cpu,和一个kmem_cache_node组成。其中kmem_cache_cpu的目的是为了从技术层面上提高CPU命中缓存,以及在同一个页面上不出现一个脏的内存(即不同时被多个CPU持有)。我把这个实现机制手工在WINDOWS下实现了一套,在开启多个kmem_cache_cpu的时候出现了个问题:

1.在释放对象的时候,判断是否是当前kmem_cache_cpu页面所在

2.如果是,则直接插入

3.如果不是,释放到邻居节点

如果是单个kmem_cache_cpu肯定没问题,但是在多个kmem_cache_cpu下,很可能会把其中一个kmem_cache_cpu已经持有的页面释放到邻居节点。举个例子:

假设一个页面地址是0-9,

kmem_cache_cpu1,持有A页面,空闲的情况为A0-A5

kmem_cache_cpu2,持有B页面,

当轮到kmem_cache_cpu2执行的时候,一个A页面的地址A6释放,程序检测到非B页面,则直接释放到邻居节点。那么这个时候A页面已经被切割成两段,并且在公共的邻居节点中。这个时候反而是增加了内存的脏度。后仔细看代码发现,源码中有这段:

<SPAN><SPAN>struct kmem_cache_cpu {
 void **freelist; /* Pointer to first free per cpu object */
 struct page *page; /* The slab from which we are allocating */
 int node;  /* The node of the page (or -1 for debug) */
 unsigned int offset; /* Freepointer offset (in word units) */
 unsigned int objsize; /* Size of an object (from kmem_cache) */
#ifdef CONFIG_SLUB_STATS
 unsigned stat[NR_SLUB_STAT_ITEMS];
#endif
};</SPAN></SPAN>

注意到struct page *page;了吗?之前一直忽略它。并且真相在分配的函数里面,

如果freelist无效的话,会多查询一次page页的地址。

2011年1月15日增

细致看了下,觉得这个地方还是有BUG。

释放上就两个步骤

1)走本地PAGE

2)NODE节点

申请上比较复杂

1)走本地freelist

2)走本页page

3)走邻居节点

4)走系统

并且做了一些看似应该释放做的事:

1)如果page和freelist都为空,则走deactivate_slab();

deactivate_slab中有很多兼容的判断,要一一舍弃。阅读源码最痛苦的就是这点。

其中用到了个值page->inuse。这个值很奇怪,它指的是在kmem_cache_cpu当前+使用中的对象,如果释放了则

进行减一,所以你看不到他的++。

1)如果page->inuse大于0,并且freelist还有值,加入邻居。这个估计是兼容的代码,之前的判断freelist不为空

2)反之,加到邻居链表。

3)如果当前邻居链表满,则释放掉

2)如果freelist为空,page不为空,很可能其他的kmem_cache_cpu释放了对象,则走load_freelist:

疑问一:就是加入邻居链表和释放加入邻居链表的冲突。从条件上看,其实两个都是依赖page->freelist是否为空加入,但是在deactivate_slab加入邻居节点后,并没有对page->freelist进行处理,如果这时候有对象释放,是否会造成重复加入?

这个疑问是我弄错了,如果page->inuse==0,表示对象都已经释放,不会触发再次释放

疑问二:在多个kmem_cache_cpu情况下,释放的元素都是放到共同的邻居页面,很有可能被其他的kmem_cache_cpu直接取到,这样就造成2个不同的kmem_cache_cpu共享同个页面,这就违背了里面缓存命中的功能。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/25391.html