SLUB的freelist指针问题

embeddedlwp

kmem_cache_cpu *c;
c->freelist与c->page->freelist含义一样吗？

embeddedlwp

顶起！

unbutun

不一样，c的freelist是fastpath的，而page的那个是slow的

也就是说，走fast的话申请很快，如果走slow的话就慢

这个和slub的配置及flags有关，c的freelist的如果在未满的情况下，会很快

embeddedlwp

回复 3# unbutun




奥，代码里确实如您所说，不过看这张图page与freelist是指向同一个slab阿。感觉就跟左手倒右手似的，为什么这里分fastpath，slowpath阿，本来就是指向同一个地方。求指点！

npuazm

恳请楼主告诉我帖子上用的图片是什么资料上的？我觉的图画的真不错

unbutun

回复 4# embeddedlwp


    fastpath 和 slowpath是指代码的流程，这张图说明不了什么问题，不用再往下追了，没意义

gxustudent

我今天刚好也在看这个问题，代码在ｍｍ/slub.c
static inline void *get_freelist(struct kmem_cache *s, struct page *page)
{
        struct page new;
        unsigned long counters;
        void *freelist;

        do {
                freelist = page->freelist;
                counters = page->counters;

                new.counters = counters;
                VM_BUG_ON(!new.frozen);

                new.inuse = page->objects;
                new.frozen = freelist != NULL;

        } while (!__cmpxchg_double_slab(s, page,
                freelist, counters,
                NULL, new.counters,
                "get_freelist"));

        return freelist;
}
从这段代码可以看到，他们是不一样的。

qiuxishi

都指向下一个空闲对象的地址，只不过一个是由kmem_cache_cpu得到（快速），另一个是遍历半满队列得到（慢速）；

mordorwww

qiuxishi 发表于 2016-02-06 11:28
都指向下一个空闲对象的地址，只不过一个是由kmem_cache_cpu得到（快速），另一个是遍历半满队列得到（慢速 ...

没遍历啊, 也挺快啊
static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,  
              unsigned long addr, struct kmem_cache_cpu *c)  
{  
    void **object;  
    struct page *new;  

    /* We handle __GFP_ZERO in the caller */  
    gfpflags &= ~__GFP_ZERO;  

    if (!c->page)/*本地CPU的slab结构中没有存储可分配的内存，则要为其寻找新的slab*/  
        goto new_slab;  

    slab_lock(c->page);  
    if (unlikely(!node_match(c, node)))//节点不匹配  
        goto another_slab;  

    stat(c, ALLOC_REFILL);  

load_freelist:  
    object = c->page->freelist;//获取一个对象  
    if (unlikely(!object))  
        goto another_slab;  
    if (unlikely(SLABDEBUG && PageSlubDebug(c->page)))  
        goto debug;  

    c->freelist = object[c->offset]; //更新freelist  
    c->page->inuse = c->page->objects;  
    /*一旦slab从partial slab链表转移到本地CPU，则page_freelist不再负责维护空闲对象了，
      因此设为NULL*/  
    c->page->freelist = NULL;  
    c->node = page_to_nid(c->page);  
unlock_out:  
    slab_unlock(c->page);  
    stat(c, ALLOC_SLOWPATH);  
    return object; //返回对象  

another_slab:  
    deactivate_slab(s, c);//将本地CPU的slab移回partial slab链表  

new_slab:  
    /*从partial slab链表中寻找一个slab*/  
    new = get_partial(s, gfpflags, node);  
    if (new) {/*获取成功则直接将该slab交给本地CPU*/  
        c->page = new;  
        stat(c, ALLOC_FROM_PARTIAL);  
        goto load_freelist;  
    }  

    if (gfpflags & __GFP_WAIT)  
        local_irq_enable();  

    /*如果partial slab链表中已无法获取slab则创建新的slab*/  
    new = new_slab(s, gfpflags, node);  

    if (gfpflags & __GFP_WAIT)  
        local_irq_disable();  

    if (new) {//创建成功  
        c = get_cpu_slab(s, smp_processor_id());//获取本地CPU的slab信息结构  
        stat(c, ALLOC_SLAB);  
        if (c->page)//本地CPU中存在slab，则移除该slab  
            flush_slab(s, c);  
        slab_lock(new);  
        __SetPageSlubFrozen(new);//冻结slab,表明slab处于本地CPU中  
        c->page = new;//本地CPU中的slab设置为新创建的slab  
        goto load_freelist;  
    }  
    if (!(gfpflags & __GFP_NOWARN) && printk_ratelimit())  
        slab_out_of_memory(s, gfpflags, node);  
    return NULL;  
debug:  
    if (!alloc_debug_processing(s, c->page, object, addr))  
        goto another_slab;  

    c->page->inuse++;  
    c->page->freelist = object[c->offset];  
    c->node = -1;  
    goto unlock_out;  
}  

mordorwww

我想问，当cpu_cache freelist空时，不是说明cpu cache里已经没有空闲内存了么，怎么还在cpu cache里搞啊