linux内核6.18 UDP接收性能提升50%:10个commit解析

前段时间看内核6.18版本发布的新闻，发布说明里有一条是UDP接收性能提升了50%，第一感觉是不太可能，内核协议栈应该已经做得很好了。 我很好奇，怎么会有如此大的性能提升，于是把关于这个性能优化相关的10个commit看了一遍,这里做一个记录。

核心操作速看：

1. 结构体瘦身与 Cache Line 重新布局（消灭 False Sharing）
2. 无锁化与减少原子操作（降低总线锁竞争）
3. 读写变量物理隔离（保护冷数据 Cache）
4. 化全局锁为 Per-Socket 锁（解决 NUMA 跨节点延迟）
5. 内存延迟释放 (Deferred Free) （消除跨核内存释放的分配器锁竞争）

这批commit的作者是Eric Dumazet，来自Google,长期做内核网络系统的开发。 根据合并记录来看，commit合计有10个,总计提升了47%的性能，主要测试数据是120字节的ipv6小包recv。

官方Merge记录

这是Linus合并这个优化系列时的官方记录，Eric Dumazet详细说明了优化思路。

（提示：代码块部分支持左右滑动查看）

Merge branch 'udp-increase-rx-performance-under-stress'    Eric Dumazet says:    ====================    udp: increase RX performance under stress    This series is the result of careful analysis of UDP stack,    to optimize the receive side, especially when under one or several    UDP sockets are receiving a DDOS attack.    I have measured a 47 % increase of throughput when using    IPv6 UDP packets with 120 bytes of payload, under DDOS.    16 cpus are receiving traffic targeting a single socket.    Even after adding NUMA aware drop counters, we were suffering    from false sharing between packet producers and the consumer.    1) First four patches are shrinking struct ipv6_pinfo size       and reorganize fields to get more efficient TX path.       They should also benefit TCP, by removing one cache line miss.    2) patches 5 & 6 changes how sk->sk_rmem_alloc is read and updated.       They reduce reduce spinlock contention on the busylock.    3) Patches 7 & 8 change the ordering of sk_backlog (including       sk_rmem_alloc) sk_receive_queue and sk_drop_counters for       better data locality.    4) Patch 9 removes the hashed array of spinlocks in favor of       a per-udp-socket one.    5) Final patch adopts skb_attempt_defer_free(), after TCP got       good results with it.

这段官方记录透露了几个关键信息：

1. 优化主要针对DDoS攻击场景下的UDP接收性能
2. 测试环境是16核CPU处理单socket，属于高并发压力测试
3. 主要解决了 False Sharing（伪共享）这个隐形性能杀手
4. 优化是系统性的，从结构体、原子操作、Cache布局、锁机制到内存管理

【背景小知识】

• Cache Line：CPU为了加速内存访问，在内部集成了cache（L1、L2、L3），访问cache和访问内存的粒度都是 Cache Line。一个 Cache Line 是64字节（8个uint64类型），哪怕是要从内存中读一个int，也是一次性读一个 Cache Line。

• False Sharing（伪共享）：当线程A访问变量a，线程B访问变量b时，它们并没有逻辑上的冲突，所以不用加锁。但是如果这个a和b刚好处于同一个 Cache Line，那么线程A修改a后，会导致整个 Cache Line 失效，线程B需要重新从内存读取。线程B修改b以后，Cache Line 会再次失效。数据在两个核心的缓存之间来回跳跃，原本并行的操作变成了事实上的串行，性能损耗极大。

commit 1-4：结构体瘦身，Cache Line布局优化

commit1 (3fbb2a6f3a70) 和 commit2 (5489f333ef99) 改动很小，都是修改结构体成员类型，把结构体里的两个指针类型，改为bool类型，因为这两个指针没有被解引用过，使用逻辑都是在判断空值。 于是两个commit每个给结构体减少7个字节，合计减少14字节：

-       conststructin6_addr           *saddr_cache;+       bool                    saddr_cache;-       conststructin6_addr           *daddr_cache;+       bool                    daddr_cache;

commit3 (9fba1eb39e2f) 有两个改动，一个是对 Cache 的优化，另一个是对数据竞争的问题修复。

staticintrawv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,if (flags & MSG_ERRQUEUE)return ipv6_recv_error(sk, msg, len, addr_len);-   if (np->rxpmtu && np->rxopt.bits.rxpmtu)+   if (np->rxopt.bits.rxpmtu && READ_ONCE(np->rxpmtu))return ipv6_recv_rxpmtu(sk, msg, len, addr_len);    skb = skb_recv_datagram(sk, flags, &err);

if 条件有短路特性，后面的判断可能不做执行。np->rxopt这个成员在后面的代码也要用到，但是np->rxpmtu几乎没用。调整顺序后，这样就保证np->rxopt这个地址永远被读到，是热点 Cache Line，下次再用，就不用访问RAM了。利用 C 语言的短路求值特性来“预热”热点 Cache，虽然能看懂原理，但是还是觉得非常巧妙。

另外，给rxopt->rxpmtu加上READ_ONCE不是性能优化，算是bug修复，防止编译器过度优化导致的数据竞争问题。

commit4 (b76543b21fbc) 的修改是调整了结构体的成员布局，把常用的成员全部放在了第一个 Cache Line（包括commit3使用的np->rxopt)，并且把发送路径用的变量和接收路径用的隔离到不同 Cache Line 上。

CPU从内存中读数据，一次不是一个字节，而是一个 Cache Line。把常用成员全放在第一个 Cache Line 上，就避免了多次访问内存，减少 Cache Miss。而把数据集中在同一个 Cache Line 上，防止其他 Core 的修改造成 False Sharing。

/* 调整前：Legacy Layout */structipv6_pinfo {structin6_addrsaddr;// 16 字节structin6_pktinfosticky_pktinfo;// 20 字节 (跨行隐患)    // ... 这里夹杂了一些不常改动的 cache 配置 ...bool saddr_cache;bool daddr_cache;    __be32 flow_label;   // 发包常用，但排在中间    __u32 frag_size;     // 中间    s16 hop_limit;       // 发包常用，排在后面    u8 mcast_hops;// ... 很多其他字段 ...structipv6_txoptions __rcu *opt;// 发包极其核心，却排在最后面！structsk_buff *pktoptions;// ...};/* 调整后：Optimized Layout (Linux 6.18) */structipv6_pinfo {/* --- 核心发送热点字段 (聚集在第一个 Cache Line) --- */structin6_addrsaddr;// 源地址 (16字节)    __be32 flow_label;              // 流标签 (4字节) - 挪到了前面    u32 dst_cookie;                 // 路由缓存验证 (4字节) - 挪到了前面structipv6_txoptions __rcu *opt;// 发送选项指针 (8字节) - 猛提到了前面    s16 hop_limit;                  // 跳数限制 (2字节) - 挪到了前面    u8 pmtudisc;                    // MTU 发现 (1字节)    u8 tclass;                      // 流量类别 (1字节)/* --- 接下来是接收选项和控制标志 --- */#ifdef CONFIG_IPV6_SUBTREESbool saddr_cache;#endifbool daddr_cache;    u8 mcast_hops;    u32 frag_size;    // ... rxopt 等字段 .../* --- 极少使用的冷数据 (踢到了最后面) --- */structin6_pktinfosticky_pktinfo;// 占空间大且发包不常用structsk_buff *pktoptions;structsk_buff *rxpmtu;structinet6_corkcork;};

commit 5-6：减少原子操作与锁竞争

commit5 (9aaec660b5be) 的修改很妙，把逻辑正确的代码，改成了工程上最优的代码。

// 修改前 rmem = atomic_read(&sk->sk_rmem_alloc);// ...if (rmem + size > rcvbuf) {// ...if (rmem > rcvbuf)goto drop; }// ...    atomic_add(size, &sk->sk_rmem_alloc);// 修改后    rmem = atomic_read(&sk->sk_rmem_alloc);// ...if (rmem + size > rcvbuf) {// .../* Accept the packet if queue is empty. */if (rmem)goto drop; }

rmem是socket已使用的内存大小，收到一个包，这里会增加，用户态recv一次，这里会减少。rcvbuf是socket允许的最大内存。

修改前的逻辑是，如果socket的rmem+当前包的size大于了rcvbuf，但是rmem还没超过rcvbuf(socket允许使用的最大内存)，就再接收一个包，然后在后续的逻辑里用 atomic（原子） 的方式增加rmem，多核竞争的情况下，这个数据在Cache里会频繁失效，导致大量 Cache Miss。

修改后的逻辑是，如果socket的rmem+当前包的size大于了rcvbuf，只要rmem不为0，就丢弃，避免了对rmem的写操作，优化了性能。

这里需要说明的是：在系统遭受 DDoS 攻击时，队列往往是满的。旧逻辑下，即使包最终会被丢弃，也会先执行一次代价昂贵的 atomic_add（随后再减回去或在别处处理），这在多核下会引发灾难性的 Cache Miss。新逻辑直接在满载时直接丢弃，连原子变量都懒得碰。

commit6 (faf7b4aefd5b) 调整了合法性检查和锁的顺序，只有合法的包才去做获取锁的逻辑，减少了锁的调用。

commit 7-8：struct sock 的读写分离

commit7 (4effb335b5da) 也是对 Cache Line 的优化，调整结构体的布局，解决 False Sharing 问题。

/* 修改前：Legacy Layout */structsock {/* ... 之前的字段 ... */// --- 缓存行 X ---atomic_t    sk_drops;          // 4字节    __s32       sk_peek_off;        // 4字节structsk_buff_headsk_error_queue;// 24字节 (关键点：它在这里！)structsk_buff_headsk_receive_queue;// 24字节// --- 缓存行 X + 1 ---struct {atomic_t  rmem_alloc;      // 4字节 <--- 【高频写热点】int       len;             // 4字节structsk_buff *head;// 8字节structsk_buff *tail;// 8字节    } sk_backlog;                  // 总计 24 字节/* 此时缓存行还没填满，只读字段紧随其后 */structdst_entry *sk_rx_dst;// 8字节 <--- 【只读字段开始】int               sk_rx_dst_ifindex; // 4字节unsignedint      sk_napi_id;  // 4字节 <--- 【高频只读】int               sk_rcvbuf;   // 4字节 <--- 【高频只读】// ...}; /* 修改后：Optimized Layout (6.18) */structsock {/* ... 之前的字段 ... *//* --- 写入密集区 (sock_write_rx) --- */atomic_t            sk_drops;    __s32               sk_peek_off;structsk_buff_headsk_receive_queue;// 往前挪了struct {atomic_t  rmem_alloc;      // 【高频写热点】int       len;structsk_buff *head;structsk_buff *tail;    } sk_backlog;structsk_buff_headsk_error_queue;// 【被挪到了这里，充当“防火墙”】/* --- 显式结束写区域 --- */    __cacheline_group_end(sock_write_rx); /* --- 只读密集区 (sock_read_rx) --- */    __cacheline_group_begin(sock_read_rx);structdst_entry *sk_rx_dst;unsignedint      sk_napi_id;         // 【现在它在另一个缓存行了】int               sk_rcvbuf;          // 【安全了！】// ...};

在修改前，struct sock 的内存布局中，sk_rmem_alloc（计数器）和一些只读/频率极低的字段挤在了同一个 Cache Line 里：

• 热数据（频繁写）：sk_rmem_alloc。每一个 UDP 包进来，都要原子增加这个值。
• 冷数据（只读/频率极低）：sk_napi_id（用于 RFS 路由）、sk_rcvbuf（限额）。

后果就是每当核心 A 修改 sk_rmem_alloc 时，CPU 硬件会强制让所有其他核心缓存中包含该变量的整个 Cache Line 失效。这意味着，即使核心 B 只是想读取一下完全没变的 sk_rcvbuf（限额），也必须重新从内存加载。

重排之后，利用 sk_error_queue 充当物理空间上的缓冲带（Padding）防火墙，把高频写的 sk_backlog 和下面只读的字段物理隔离开：

• 写操作：核心 A 在写 sk_rmem_alloc 时，只会污染到其他同样需要写的字段（如 sk_receive_queue.tail）。
• 读操作：核心 B 读取 sk_rcvbuf 时，该字段所在的 Cache Line 处于 Shared 状态，永远不会因为 rmem_alloc 的变化而失效。

commit8 (9db27c80622b) 有两个改动，第一个还是 Cache Line 相关的优化。

#ifdef CONFIG_MEMCGstructmem_cgroup *sk_memcg;#endif#ifdef CONFIG_XFRMstructxfrm_policy __rcu *sk_policy[2];#endifstructnuma_drop_counters *sk_drop_counters; __cacheline_group_end(sock_read_rxtx); __cacheline_group_begin(sock_write_rxtx);socket_lock_t  sk_lock; u32   sk_reserved_mem;int   sk_forward_alloc; u32   sk_tsflags;

作者发现，sk_drop_counters这个成员在sock_read_rxtx这组Cache末尾，刚好导致sock_write_rxtx这一组Cache没有对齐，把它踢出去就能对齐了，于是调整了这个成员的位置。

第二个改动，是针对丢包统计的优化，原来的方案，丢包统计是用sk_drops_inc函数：

staticinlinevoidsk_drops_inc(struct sock *sk){ sk_drops_add(sk, 1);}staticinlinevoidsk_drops_add(struct sock *sk, int segs){structnuma_drop_counters *ndc = sk->sk_drop_counters;if (ndc)  numa_drop_add(ndc, segs);else  atomic_add(segs, &sk->sk_drops);}

sk_drop_counters在sock结构体里是一个指针，修改这个计数器时，访问指针数据要做一次内存操作。新方案里，直接使用了udp.h里的drop_counters，避免了一次指针访问。

commit9： Per-Socket自旋锁替代全局锁数组

commit9 (3cd04c8f4afe) 之前的旧方案，为了避免内存浪费，并没有给每个socket分配一个自旋锁，而是设计了一种公用机制。 如代码所示：udp_busylocks 是一个全局的自旋锁数组，在UDP协议初始化函数里，数组被初始化。 socket需要加锁的时候，先计算hash，映射到这个数组的某一把锁上。

staticspinlock_t *udp_busylocks __read_mostly;void __init udp_init(void){// ...for (i = 0; i < (1U << udp_busylocks_log); i++)  spin_lock_init(udp_busylocks + i);// ...}

这里面有两个问题：

1. udp_init函数在某个CPU A上执行，在多NUMA环境下，这个初始化的内存也在CPU A的NUMA上，另一个NUMA访问这些锁的时候，就要跨NUMA访问，延迟很高。
2. 不同的 Socket 可能会哈希到同一把锁上。这意味着两个完全无关的进程（比如一个是 DNS，一个是游戏逻辑）可能会因为碰巧分到了同一把锁而互相排队，导致性能下降（共享肯定比不过独占）。

这个commit就是以空间换时间，给每个socket实现了一把自旋锁，在socket创建的时候做初始化。

structudp_sock {structhlist_nodetunnel_list;structnuma_drop_countersdrop_counters;+   spinlock_t              busylock ____cacheline_aligned_in_smp;};staticinlinevoidudp_lib_init_sock(struct sock *sk){// ...    sk->sk_drop_counters = &up->drop_counters;+   spin_lock_init(&up->busylock);    skb_queue_head_init(&up->reader_queue);// ...}

并且给自旋锁加了____cacheline_aligned_in_smp，让这把锁独占一个 Cache Line。解决了上面两个问题，代价就是 UDPv6 socket 的size增大到了1600字节。

commit 10：内存延迟释放 (Deferred Free)

commit10 (6471658dc66c) 把吞吐量提升了20%-30%，它是把TCP上的延迟释放（Deferred Free）移植到了UDP。

在以前的处理流程中：

• CPU A（软中断 BH 路径）负责从网卡接收数据包，并为 skb 分配内存。
• CPU B（用户态路径）调用 recvmsg() 读取数据，并执行 consume_skb() 释放内存。

当 CPU B 尝试释放由 CPU A 分配的内存时，会触发内存分配器（如 SLUB）的跨核操作。这会导致：

• 缓存行抖动：分配器内部的状态（如本地 CPU 缓存池）需要在两个核心之间同步。
• 锁竞争：在高并发下，多个用户态核心同时释放来自不同软中断核心的内存，会引发严重的分配器锁竞争。

通过引入 skb_attempt_defer_free() 改变了这一现状：当用户态（CPU B）处理完 UDP 包后，不再直接执行昂贵的释放操作。如果条件允许（skb 非共享），内核会将这个 skb 放入一个远程 CPU 队列，重新投递回当初分配它的 CPU A。CPU A 在下一次处理软中断时，会批量释放这些“归乡”的包。

这其实是把跨核的内存管理锁竞争，巧妙地转换成了单核内部的 SoftIRQ 批量处理。此时，内存的分配和释放都发生在 CPU A 的 L1/L2 缓存中，完全是本地操作。

voidskb_consume_udp(struct sock *sk, struct sk_buff *skb, int len)if(unlikely(READ_ONCE(udp_sk(sk)->peeking_with_offset)))sk_peek_offset_bwd(sk, len);+       if (!skb_shared(skb)) {+               if (unlikely(udp_skb_has_head_state(skb)))+                       skb_release_head_state(skb);+               skb_attempt_defer_free(skb);+               return;+       }+if (!skb_unref(skb))return;

总结：本以为 Linux 内核的协议栈已经千锤百炼，没什么油水可榨了，没想到 Eric Dumazet 依然能从中抠出 50% 的性能提升。这 10 个 Commit 大部分都是在和 CPU Cache 较劲，只有对计算机体系结构、多核并发、内存分配器有极深的理解，才能发现这些隐秘的瓶颈。