Linux内核函数是否均按0x10对齐？该对齐规则的设计原因是什么？

是否所有内核函数都遵循0x10对齐规则 #

这个规则不是全场景硬约束，只是x86_64架构下主流发行版默认配置编译内核的普遍特征，以下场景就不满足对齐要求：

• 自定义编译内核时如果关闭了函数对齐优化、开启了-Oz之类的极限体积优化选项，函数不会按16字节对齐
• 非x86_64架构的对齐规则不统一，多数32位嵌入式架构默认采用4字节、8字节函数对齐，不会遵循0x10对齐要求
• 内核中少量手写汇编桩函数、标记了packed属性的特殊函数，不会触发编译器的对齐逻辑
• 运行时动态生成的代码，比如eBPF JIT编译结果、ftrace动态生成的桩代码，对齐规则完全看生成逻辑的需求，没有统一标准

常规发行版默认编译的x86_64生产内核中，99%以上的静态编译内核函数都符合地址末尾半字节为0x0的特征，这也是5.7版本之后内核不再导出kallsyms_lookup_name时，暴力内存搜索方案能靠这个特征过滤大量无效地址、把搜索速度提升几十倍的基础，但别把这个特征当成跨版本、跨架构通用的强规则，不然在特殊编译内核、非x86平台上跑直接就会崩。

内核采用0x10对齐设计的具体原因 #

这个对齐设计是性能、硬件要求、功能实现多方面权衡的结果，核心原因有四点：

• 处理器取指性能优化：现代x86_64处理器的取指单元、分支预测器对16字节边界对齐的函数入口处理效率更高，跨16字节边界、跨缓存行的跳转指令会带来十多个时钟周期的额外开销，函数入口16字节对齐可以最小化函数调用、跳转时的取指惩罚。
• 适配x86_64 ABI与指令集要求：x86_64系统V ABI明确要求函数调用时栈指针必须16字节对齐，才能满足SSE/AVX等SIMD指令的内存操作数对齐要求，函数自身地址16字节对齐可以简化栈帧调整时的对齐计算逻辑，省掉不少多余的对齐指令开销。
• 支撑内核动态特性实现：ftrace、kprobes、内核热补丁（livepatch）等动态追踪、热升级功能，都需要在函数入口处插入断点、跳转指令，16字节对齐的函数入口和前序函数的尾部指令有明确的地址间隔，不会出现指令重叠问题，大幅降低了打桩逻辑的复杂度。
• 降低内存管理开销：内核slab/slub分配器的常用小对象分配粒度很多场景默认是16字节，函数按16字节对齐可以和内存分配规则匹配，减少代码段的内存碎片，提升指令TLB的命中率。

内容的提问来源于stack exchange，提问作者HnlyWk