linux内存分配slub的几个疑问

zbzyhvgodz

　　对于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页面已经被切割成两段，并且在公共的邻居节点中。这个时候反而是增加了内存的脏度。后仔细看代码发现，源码中有这段：
　　


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
};
　　  注意到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共享同个页面，这就违背了里面缓存命中的功能。