Linux内核中sched_class结构为何需内存紧密对齐且连续？

背景信息 #

Linux内核中，各类调度策略（如SCHED_NORMAL、SCHED_FIFO）都通过struct sched_class实现，对应的实例通过DEFINE_SCHED_CLASS()宏定义：

#define DEFINE_SCHED_CLASS(name) 
  const struct sched_class name##_sched_class 
    __aligned(__alignof__(struct sched_class)) 
    __section("__" #name "_sched_class")

这些调度类实例通过链接脚本vmlinux.lds.h的SCHED_DATA段按优先级顺序排列：

#define SCHED_DATA              
  STRUCT_ALIGN();               
  __sched_class_highest = .;        
  *(__stop_sched_class)         
  *(__dl_sched_class)           
  *(__rt_sched_class)           
  *(__fair_sched_class)         
  *(__idle_sched_class)         
  __sched_class_lowest = .;

在sched_init()初始化早期，会执行严格的内存布局检查：

BUG_ON(&idle_sched_class != &fair_sched_class + 1 ||
       &fair_sched_class != &rt_sched_class + 1 ||
       &rt_sched_class   != &dl_sched_class + 1);

问题 #

已知调度类需按优先级排序，但为何必须保证无内存填充、硬检查&a == &b + 1，而非仅依赖链接脚本定义的逻辑顺序？

回答 #

• 实现极致高效的优先级遍历：内核调度逻辑中频繁需要从高到低遍历调度类（比如查找下一个可调度的最高优先级进程）。如果调度类是连续无填充的内存布局，直接通过指针递增就能完成遍历，无需维护额外的链表、索引结构，这种O(1)的指针操作能最大化遍历性能，避免链表遍历的开销。
• 及时发现链接配置错误：链接脚本定义的是逻辑上的优先级顺序，但编译或链接过程中，可能因结构体对齐规则、段属性设置等原因，在调度类实例之间插入填充字节，导致逻辑顺序和实际内存顺序不符。硬检查能在系统启动初期就触发BUG，避免后续调度逻辑出现难以排查的异常——比如误访问错误内存区域引发崩溃，或者高优先级进程被低优先级调度类错误处理。
• 确保跨环境的布局一致性：不同CPU架构、不同编译选项对结构体对齐的要求可能不同，比如某些架构会强制要求特定大小的结构体按更大的边界对齐。硬检查能保证无论编译环境如何，调度类的内存布局都严格符合预期，不会因环境差异破坏优先级的连续性。
• 简化调度逻辑的实现：内核中大量调度相关代码依赖这种连续内存布局，比如for_each_class(class)这类遍历宏就是基于指针递增实现的。如果内存布局不连续，这类宏需要重构，不仅增加代码复杂度，还容易引入新的逻辑bug。

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