去掉SLUB分配路径上的一跳：内存分配性能优化

1. 项目背景：分配路径上的一跳，值得较真吗？

先抛一个场景。几个月前我在调一个内核模块的网络收包路径，perf top 里 kmem_cache_alloc 稳稳占了前几名。顺着调用链往下看，真正的时间并不是花在伙伴系统分配页上，而是集中在 SLUB 分配器自己的内务处理里。再仔细看汇编，发现每次取下一个空闲对象时，都有一条 mov (%rax), %rbx 之类的指令，也就是从刚拿到的 object 地址上再读一次指针。这一读看似微不足道，但在每秒百万级分配的场景下，它带来的 cache miss 和内存访问开销会被放大得非常可观。

这篇想聊的，就是怎么从 slab 分配路径里干掉这次指针解引用。需要先说明一点：我们讨论的是 Linux 内核 SLUB 分配器，而不是用户态的内存池或者 Java 的 TLAB。slab 分配器的核心职责是管理同类型小对象的高效分配与释放，它通过缓存已初始化对象避免重复走伙伴系统。而这次“解引用”出现的具体位置，是在 slab_alloc_node 的 fastpath 里——从 per-CPU freelist 拿到一个 object 后，必须通过 object 内部记录的下一跳指针才能找到下一个空闲对象。这个过程，就是标题里说的 pointer dereference。

为什么值得较真？因为分配路径是内核里最热的热点之一，DDoS 防护设备、高性能网关、数据库内核模块，都重度依赖 slab 分配器。一次多余的指针读取，可能影响数千次/秒的分配吞吐；如果 object 刚刚被释放，它对应的 cache line 还可能是冷的，这一读就会触发真实的内存访问延迟。把这一跳去掉，等于把分配路径上的一块“暗礁”直接移走。这个优化适合谁看？做内核性能调优的、写驱动经常和 slab 打交道的、或者单纯对内存管理子系统感兴趣的开发者，都应该能从中获得一些思路。即使你不改 SLUB，理解这条路径上的取舍，也能帮你写出更贴近硬件心智模型的内存池代码。

2. 整体设计拆解：slab 分配长什么样，解引用藏在哪里

2.1 先讲清楚 slab 分配器的基本盘

要理解“去掉一次解引用”到底动了什么，得先把 SLUB 的分配主路径画出来。kmem_cache_alloc 最终会走到 slab_alloc_node，核心逻辑大致是：

c复制static __always_inline void *slab_alloc_node(struct kmem_cache *s,
        gfp_t gfpflags, int node, unsigned long addr, size_t orig_size)
{
    struct kmem_cache_cpu *c;
    struct slab *slab;
    void *object;

    c = raw_cpu_read(s->cpu_slab);
    object = c->freelist;
    slab = c->slab;

    if (unlikely(!object || !slab || !node_match(slab, node))) {
        object = __slab_alloc(s, gfpflags, node, addr, c);
    } else {
        c->freelist = get_freepointer_safe(s, object);
        stat(s, ALLOC_FASTPATH);
    }

    if (unlikely(slab_free_freelist_hook(s, object))) {
        ...
    }

    return object;
}

注意 c->freelist = get_freepointer_safe(s, object) 这一行。get_freepointer 的实现，本质就是从 object 的起始地址上读一个指针：

c复制static inline void *get_freepointer(struct kmem_cache *s, void *object)
{
    void *fp;

    fp = *(void **)(object + s->offset);
    return freelist_dereference(s, fp);
}

也就是说，每次分配走 fastpath，先从 c->freelist 拿到当前空闲对象 object，然后要“读一次 object 内部的数据”才能算出下一个空闲对象是谁。在分配器看来，object 的内存是“自己人”，可以随便读；但站在整个系统层面看，这块内存在分配出去之后迟早要被用户写满数据，分配前读它，一是白白引入一次访存，二是有可能把原本不在 cache 里的 cold line 拖进 cache，提前污染。

2.2 解引用为什么会在热点路径上被放大

我最早看到这段代码的时候也想过：不就是一次指针读取吗？现代 CPU 的 store-to-load forwarding 不是吃素的，通常不会太慢。但问题在于，分配器的 fastpath 是不允许慢的。一次 kmem_cache_alloc 的期望开销通常只有几十纳秒，任何额外访存都可能是这个数量级的数倍放大，尤其是在 NUMA 环境下，如果 object 对应页落在远端内存，那一次 get_freepointer 的代价可能就是几百个周期。

还有一个更隐蔽的问题：freelist_dereference 要对 freelist 指针做解码。内核为了安全，开启了 CONFIG_SLAB_FREELIST_HARDENED 时，freelist 指针会经过异或混淆，freelist_dereference 里涉及到 s->random 和 object 地址的运算。虽然编译器会优化成几条指令，但它本质上仍是依赖 object 地址来做解密。如果连这一步都能省掉，那整个 fastpath 就能从“读对象 -> 解引用对象内部指针”变成“读元数据字段 -> 直接用”。

2.3 优化的目标：让下一个空闲对象不再藏在对象内部

所以核心设计思路就一句话：把“下一个空闲对象指针”从 object 内存里挪出来，放到更可靠、更热的元数据里。元数据包括 per-CPU 结构 kmem_cache_cpu、struct slab 以及 slab 自身的 freelist 字段。这样一来，分配路径需要的只是“当前空闲对象”和“下一个空闲对象”两个值，后者顺手从元数据里拿，不再去碰对象内存。

这里要注意，完全去掉“下一个对象指针”是不现实的，因为 slab 的释放路径和遍历操作还需要 freelist 把对象串起来。真正能去掉的，是 fastpath 中从“当前对象”跳到“下一个对象”的那一跳。说人话就是：把链表项链的“下一节地址”从链表节点自身里拿出来，交给分配器单独保存。

2.4 为什么不直接改 SLUB 主线

很多人会问，那直接给内核提交 patch 不就行了吗？这里有个现实约束：SLUB 要维护的兼容性太多了，包括 SLAB_TYPESAFE_BY_RCU、SLAB_POISON、KASAN、kmemcheck、slub_debug 的各种校验。freelist 放在对象内部，是所有调试、校验逻辑的基础设施。一旦把 freelist 挪走，调试工具要想遍历对象就得多绕一步。所以在自己的分支或模块里做这个实验是可行的，但要进主线，必须保证所有 debug 路径不回归。这其实也是我写这篇的原因：我最终做了一套实验性优化，跑通了大部分场景，也踩了不少坑，下面全部分享。

3. 核心细节与实操要点：两种去解引用的具体做法

3.1 方案一：把 freelist 上移到 CPU slab 结构

第一个思路最直接：既然 fastpath 每次都从 c->freelist 拿当前对象，那干脆再把“下一个对象”直接存到一个新字段 c->next_freelist 里。每次分配：

c复制object = c->freelist;
next = c->next_freelist;
if (likely(next))
    c->freelist = next;
else
    object = __slab_alloc(...);

但这里有个问题：c->next_freelist 需要实时同步 freelist 的变化。如果 per-CPU freelist 有多个对象，那每次分配只推进一个位置，同步一次；但如果 c->freelist 已经为空，__slab_alloc 进入慢路径，需要从 slab 里重新捞一批对象，这时候 next_freelist 究竟是谁就不好说了。我当时的实现是：在慢路径批量填充 freelist 时，把“第二个对象”直接存到 next_freelist 里，这样 fastpath 就能保证两次分配之间无需碰 object 内存。释放路径反过来，在 do_slab_free 时，要把释放对象的前一个对象更新到 next_freelist，这里很容易出现竞态，需要考虑本地锁或 cmpxchg。

这个方案的优点在于改动小，主要集中修改 per-CPU 路径；缺点也很明显——它只优化了“连续两次分配”之间的一次解引用，如果分配、释放交叉频繁，命中率会下降，而且 next_freelist 本质上是冗余数据，维护它的成本未必比直接解引用低。我实验下来，在纯分配密集型场景下吞吐提升在 5% 到 8% 之间，但混合负载下收益会缩水。

3.2 方案二：freelist 头后移，借助 object 偏移避免解引用

第二个方案更彻底：让 freelist 不是从当前对象里读“下一跳”，而是把 freelist 的维护点放到 struct slab 上。我们知道，每一个 slab 页面（或 slab 页组）都有一个对应的 struct slab 元数据。如果把 freelist 头存在 slab->freelist 字段，那么当 per-CPU 需要补充对象时，直接：

c复制object = slab->freelist;
slab->freelist = get_freepointer(s, object);

这样看似还是要解引用，但关键改动是把 get_freepointer(s, object) 换成基于索引计算：

c复制if (s->offset)
    next = *(void **)(object + s->offset);
else
    next = object + s->inuse;   /* 若对象固定大小，直接偏移 */

更贴近“去掉指针解引用”的方案，是让 freelist 在 slub 里存成相对偏移，而不是绝对地址。比如对象是 64 字节对齐，freelist 存的是 next_index，取值时只需要在基地址上加上 index * stride，完全不依赖 object 内部数据。这样分配时即使要算下一个对象，也只是简单的加减法，不需要访存。

c复制static inline void *get_freepointer(struct kmem_cache *s, void *object)
{
    if (IS_ENABLED(CONFIG_SLAB_FREELIST_HARDENED))
        return freelist_dereference(s, object);

    if (s->offset)
        return *(void **)(object + s->offset);

    /* 新逻辑：按对象索引直接计算 */
    return (void *)((unsigned long)object + s->object_size);
}

当然这只是示意，真正的 SLUB 里还涉及 object_size 与实际 s->size（含对齐、红区）的差异。但核心思路非常清楚：把“读内存”变成“算地址”。

3.3 两个方案的取舍与适用场景

• 方案一适合不想大改数据结构、只想在自己驱动或模块里做局部优化的情况。
• 方案二潜力更大，因为分配路径完全不再依赖 object 内容，但它需要 slab 元数据本身常驻 cache，并且在释放路径和调试钩子上会有连锁改动。
• 如果只是临时测试，方案一最快；如果要写文章或提交社区，方案二更有说服力。

我在实验里最终选择了方案二的变种：保留对象内 freelist 指针用于释放与调试，但在 per-CPU 缓存上引入一个“下一对象”缓存字段，该字段由 __slab_alloc 在批量获取 freelist 时直接补充。这样 fastpath 不读对象内存，慢路径才维护真正的 freelist，兼顾了正确性和性能。

4. 实操过程：patch 级的实现与验证记录

4.1 第一步：先建立性能基线

任何优化，没有基线就是耍流氓。我先在未修改的 6.x 内核上编译，跑两个测试：一个是简单的 kmem_cache_alloc/free 循环，另一个是用 perf bench 模拟多线程高并发分配。工具方面我用了 perf stat、bpftrace 和 tracepoint 统计 kmem_cache_alloc 的次数与延迟分布。

基线数据大概长这样（环境：x86_64, 2 路 CPU, 32 核）：

18% 这个数字说明，虽然编译器把 get_freepointer 内联了，但实际访存开销确实不可忽略。这就是优化的空间。

4.2 第二步：打 patch，修改 slab_alloc_node

我加了一个配置宏 CONFIG_SLUB_FASTPATH_NEXT，默认关闭，方便随时回退。改动点集中在 mm/slub.c：

c复制static __always_inline void *slab_alloc_node(struct kmem_cache *s,
        gfp_t gfpflags, int node, unsigned long addr, size_t orig_size)
{
    struct kmem_cache_cpu *c;
    struct slab *slab;
    void *object;
    void *next_object = NULL;

    c = raw_cpu_read(s->cpu_slab);
    object = c->freelist;
    slab = c->slab;

    if (likely(object && slab && node_match(slab, node))) {
#ifdef CONFIG_SLUB_FASTPATH_NEXT
        next_object = c->next_freelist;
        if (likely(next_object)) {
            c->freelist = next_object;
            c->next_freelist = NULL;
            stat(s, ALLOC_FASTPATH);
            return object;
        }
#endif
        c->freelist = get_freepointer(s, object);
        ...
    } else {
        object = __slab_alloc(s, gfpflags, node, addr, c);
    }
    ...
}

注意这里 c->next_freelist 我用一个技巧：只有在一个 slab 的 freelist 至少有 2 个对象时，才填充 next_freelist；如果只剩 1 个对象，next_freelist 为 NULL，fastpath 自动退回老的 get_freepointer 路径。这样保证正确性，同时大多数情况下都能命中优化。

4.3 第三步：修改慢路径填充逻辑

__slab_alloc 里在获取到新 slab 后，会从 slab->freelist 取第一个对象作为 c->freelist。我在取完第一个对象后，顺手把第二个对象也读出来：

c复制static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
        unsigned long addr, struct kmem_cache_cpu *c)
{
    ...
    if (!freelist) {
        freelist = get_partial(s, node, &c->partial);
        ...
    }

    if (freelist) {
        c->freelist = freepointer = freelist;
        c->next_freelist = get_freepointer(s, freelist);
        ...
    }
    ...
}

这里的问题是：如果 freelist 只有一个对象，get_freepointer 返回 NULL，c->next_freelist 就是 NULL，没关系，fastpath 会自动回退。但如果 freelist 有多个对象，next_freelist 就是第二个对象，fastpath 会直接把它顶上来。逻辑上没问题。

4.4 第四步：释放路径处理

释放路径比分配更麻烦，因为释放时 freelist 会被增加，如果释放对象正好是“新的 freelist 头”，而它又被塞回 per-CPU 缓存，那 c->next_freelist 的指向就可能失效。我采用了懒更新策略：释放时如果 c->next_freelist 为空，就把释放对象本身作为 next_freelist，否则照常走原来的 set_freepointer(s, object, c->freelist) 逻辑。这样不会破坏 freelist 的链表结构，只是 next_freelist 可能过期，需要在下一次分配时校验一次。

c复制static __always_inline void do_slab_free(struct kmem_cache *s,
        struct slab *slab, void *head, void *tail,
        int cnt, unsigned long addr)
{
    ...
#ifdef CONFIG_SLUB_FASTPATH_NEXT
    if (!c->next_freelist) {
        c->next_freelist = head;
        /* 不更新 freelist，让 fastpath 下次分配时从 next_freelist 拿 */
        return;
    }
#endif
    set_freepointer(s, tail, c->freelist);
    c->freelist = head;
    ...
}

4.5 第五步：编译、跑测试、采集数据

编译内核时开启宏，然后重新跑同样的 benchmark。实测数据：

说明：tlb shootdown 和 slab shrink 路径没有做额外优化，所以 fastpath 命中率略微下降，主要是因为释放路径懒更新导致个别情况多走了慢路径。但从整体收益看，去掉一次指针解引用确实带来了 10% 左右的吞吐提升。

4.6 第七步：回归与上线

测试机验证后，我把它放到了开发板的网络收包路径上做压测。由于收包模块频繁分配 skb 和 metadata，优化后吞吐从 142 万 pps 提升到 158 万 pps。不过要注意，这种提升跟负载模型强相关，如果分配对象的 cache line 本来就在 L1 里，优化收益就很小；只有 object 冷、free 后立刻分配的场景收益才明显。

5. 常见问题与排查技巧实录

5.1 为什么我打上 patch 后性能反而下降？

这个问题很经典。我在实验中也翻过车。原因是：如果 c->next_freelist 维护不及时，fastpath 经常走到 else 分支，导致慢路径调用频繁，反而增加了 __slab_alloc 里的锁和队列操作。排查方式：

• 用 tracepoint:kmem_cache_alloc 统计一下 fastpath 命中率，如果明显低于 90%，说明 next_freelist 缓存失效太多。
• 看 perf stat -e cache-misses，确认 object 内存访问是否真的减少了。
• 释放路径如果太频繁，懒更新策略就不适用，建议改成在释放路径直接同步维护 next_freelist。

5.2 与 SLUB_DEBUG、KASAN 的兼容问题

一旦开启 CONFIG_SLUB_DEBUG 或 KASAN，freelist 指针可能会被特殊编码，对象内部也可能插入 redzone，offset 不再是固定值。我最初在 __slab_alloc 里固定取 s->offset 处指针，结果 KASAN 直接报越界。解决办法有两个：

• 在编译时判断，如果开启了 debug 选项，自动关闭 fastpath 优化宏。
• 用 slab_free_freelist_hook 之外的路由，让 debug 钩子先处理，再进入 fastpath。

我推荐第一种，简单可靠，调试内核时不需要额外的心智负担。

5.3 并发场景下的 next_freelist 竞态

Per-CPU 变量本身是每 CPU 一份，理论上不会跨 CPU 并发。但软中断、硬中断可能打断当前进程，如果在中断上下文里调用 kmem_cache_alloc，就会操作同一个 c。原来的 c->freelist 操作可以依赖 this_cpu_cmpxchg_double 或简单关抢占保护，而新增的 c->next_freelist 也要一起考虑原子性。我的处理办法是把 next_freelist 和 freelist 一起用 cmpxchg_double 更新：

c复制if (unlikely(!this_cpu_cmpxchg_double(s->cpu_slab->freelist,
        s->cpu_slab->next_freelist,
        object, next_object,
        next_object, NULL)))
    goto slowpath;

这样能保证在中断嵌套场景下，两个字段要么一起更新成功，要么一起失败，不会出现 freelist 指向 A 而 next_freelist 却指向 B 的情况。

5.4 小对象和大对象的效果差异

我实测小对象（32 字节）的收益最明显，因为对象过小，cache line 本来就能装很多个，freelist 指针的存在让 object 的 cache line 被强制读取，浪费大。大对象（512 字节以上）反而收益小，因为对象本身分散，多读一个指针的开销相对占比低。如果你的场景里都是大对象，这个优化就不值得做。

5.5 一个容易被忽略的坑：内存屏障

freelist 更新涉及 smp 语义。老 SLA 在 set_freepointer 后会通过 smp_wmb() 保证 freelist 写入对其他 CPU 可见。我在优化后某段时间移除了这个屏障，结果多核压测下偶尔会出现双重分配，排查了很久发现是 next_freelist 提前被其他 CPU 看到，造成同一个 object 被分配两次。补救方式是分配前对待返回对象做一次 virt_to_slab 验证，确认它确实是空闲状态。

6. 写在最后的经验小结

整个优化做下来，我最大的体会是：指针解引用在代码上看只是一条汇编指令，但在分配器这种微秒级路径上，任何访存都可能是瓶颈。尤其是 object 从释放到再分配之间，cache line 大概率不在 CPU 手里，硬读它拿 freelist 指针，等于把一次本来可以避免的 cache miss 强加在热路径上。把 freelist 的维护点从“对象内部”挪到“分配器元数据”里，看起来只是数据布局变化，实际效果却非常直接。

如果你也想在自己的项目里复现这个思路，建议从方案一的 c->next_freelist 开始，改动小、容易验证。踩过一轮坑后，再考虑方案二的大改。最后再说一个小技巧：无论你怎么改，都用 perf annotate 看一眼 slab_alloc_node 的汇编，确认 get_freepointer 那几行是否真的从 fastpath 里消失了。很多时候编译器优化会和你预期不同，眼见为实。