简介

在传统 Linux 内核调度体系中，CFS 公平调度、SCHED_FIFO、SCHED_RR、SCHED_DEADLINE 均为内核静态编译固化的调度策略。若业务场景需要定制化调度逻辑，以往只能修改内核源码、重新编译内核并重启服务器，不仅流程繁琐、停机成本高，还无法适配云服务器、工业实时网关、集群算力节点这类7×24 小时不间断运行的生产环境。

Linux 6.6 及以上版本正式合入Sched-Ext（可扩展调度器） 架构，依托 BPF 字节码实现调度策略用户态定义，同时原生支持热插拔运行机制：无需重启系统、无需中断业务进程，即可动态加载自定义调度算法、切换全局调度规则、卸载第三方调度策略，出错后内核还能自动回退至原生 CFS 调度，极大提升了 Linux 调度体系的灵活性与可定制性。

该特性广泛应用于边缘算力调度、服务器算力动态调优、工业嵌入式实时调度、容器集群进程优先级管控、低时延网络服务调度等场景。对于内核研发工程师、嵌入式 Linux 开发、云原生运维、实时系统调优人员而言，掌握 Sched-Ext 热插拔加载与卸载原理，是脱离原生固定调度策略、实现业务定制化调度、优化整机调度时延、撰写内核调度方向论文与技术报告的核心必备技能。本文从底层原理、环境搭建、内核配置、BPF 调度代码编写、动态加载卸载实操、内核源码逻辑拆解、问题排查全维度讲解，全程采用一线工程师实战视角，剔除模板化话术，附带可直接编译运行的完整代码与生产可用命令。

一、核心概念与专业术语解析

1.1 Sched-Ext 可扩展调度器基础定义

Sched-Ext 全称Scheduler Extensible，是 Linux 内核新增的独立调度类别，内核宏定义为SCHED_EXT，核心设计思想是调度逻辑下沉至用户态 BPF 程序，内核仅保留调度框架与基础调度基础设施。

  • 内核不再硬编码全部调度算法，仅提供统一调度回调接口；
  • 用户态通过编写 BPF 程序实现选核、入队、分发、时间片管控等调度逻辑；
  • 所有自定义调度策略均以 BPF 对象形式存在，支持动态挂载与解绑。

1.2 热插拔调度核心特性

  1. 无停机加载：系统正常运行、业务进程持续执行时，加载自定义 Sched-Ext 调度策略并全局生效；
  2. 无损卸载：卸载 BPF 调度程序后，所有受管控进程自动切回 CFS 原生调度，无进程崩溃、无调度死锁；
  3. 异常自动回退：BPF 调度逻辑出现死循环、内存越界、调度阻塞等异常，内核自动禁用 Sched-Ext，恢复默认调度；
  4. 局部 / 全局切换：支持两种管控模式，全局管控所有普通进程，或仅管控指定SCHED_EXT策略进程。

1.3 核心数据结构与调度接口

1.3.1 调度操作结构体 sched_ext_ops

该结构体是 BPF 调度程序与内核调度层交互的核心契约，所有自定义调度逻辑都需要挂载至该结构体回调函数中，定义路径：include/linux/sched/ext.h

struct sched_ext_ops {
    const char              *name;          // 调度策略名称，唯一标识
    u64                     flags;          // 调度模式标识（全局/局部切换）
    int                     init;           // 调度器初始化回调
    void                    exit;           // 调度器退出销毁回调
    s32                     select_cpu;    // 进程唤醒时选择运行CPU
    void                    enqueue;        // 就绪进程入队回调
    void                    dispatch;      // CPU选取待运行进程分发回调
    void                    tick;          // 时钟节拍调度回调
    void                    running;       // 进程开始运行回调
    void                    stopping;      // 进程停止运行回调
    unsigned int            dispatch_max_batch;
};
1.3.2 调度分发队列 DSQ

Sched-Ext 摒弃传统 CPU 运行队列，采用DSQ 分发队列作为进程调度载体：

  • SCX_DSQ_GLOBAL：全局共享调度队列；
  • SCX_DSQ_LOCAL：单 CPU 本地私有调度队列；
  • 支持用户态 BPF 自定义创建多级优先级 DSQ 队列，实现优先级调度。

1.4 热插拔运行核心流程

  1. 加载阶段：用户态加载编译完成的 BPF 调度程序，注册sched_ext_ops回调至内核；
  2. 生效阶段：内核开启 Sched-Ext 调度，根据 flags 标识切换进程调度归属；
  3. 运行阶段：进程唤醒、就绪、切换、时钟中断全部走 BPF 自定义回调逻辑；
  4. 卸载阶段：用户态主动销毁 BPF 调度对象，内核清空回调指针，进程切回原生调度；
  5. 异常兜底：调度卡死、BPF 校验失败、资源泄漏，内核强制关停 Sched-Ext。

1.5 关键状态文件接口

内核通过 sysfs 文件系统暴露 Sched-Ext 运行状态，也是热插拔状态观测核心入口：

/sys/kernel/sched_ext/state        # 当前调度器状态：enabled/disabled
/sys/kernel/sched_ext/root/ops     # 当前正在运行的自定义调度器名称
/sys/kernel/sched_ext/enable_seq   # 调度器加载次数计数器

二、环境准备与内核编译配置

2.1 软硬件环境标准配置

环境分类 版本与配置要求
操作系统 Ubuntu 22.04 / Debian 12 64 位
内核版本 Linux 6.6 LTS、Linux 6.7、Linux 6.8（必须 6.6 及以上）
硬件配置 x86_64 架构，4 核 CPU+8G 内存，支持 BPF JIT 编译
编译依赖 gcc、clang、llvm、libbpf-dev、bpftool、make、flex、bison
调试工具 bpftrace、ftrace、perf、gdb、drgn

2.2 依赖组件一键安装命令

可直接复制执行，完成所有编译与调试环境部署

# 更新软件源
sudo apt update && sudo apt upgrade -y

# 安装基础编译工具
sudo apt install build-essential make flex bison libncurses-dev libelf-dev libssl-dev -y

# 安装BPF编译全套依赖
sudo apt install clang llvm libbpf-dev bpftool bpftrace -y

# 安装调试与内核分析工具
sudo apt install trace-cmd drgn gdb -y

2.3 内核源码获取与 Sched-Ext 功能开启

2.3.1 下载指定版本内核源码
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz
tar -xf linux-6.6.tar.xz
cd linux-6.6
2.3.2 内核关键配置项（必须全部开启）
# 继承当前系统内核配置
cp /boot/config-$(uname -r) .config
make menuconfig

依次开启以下核心配置：

# 基础BPF支持
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_DEBUG_INFO_BTF=y

# 核心Sched-Ext调度器开关
CONFIG_SCHED_CLASS_EXT=y

# 调试与跟踪配置
CONFIG_FTRACE=y
CONFIG_SCHED_DEBUG=y
CONFIG_KGDB=y
2.3.3 编译安装内核并重启
# 多线程编译
make -j$(nproc)
# 安装内核模块
sudo make modules_install
# 安装内核镜像
sudo make install
# 更新系统启动项
sudo update-grub

重启系统后，执行uname -r确认内核版本为 6.6 及以上，配置生效。

2.4 内核自带示例调度器编译

内核源码内置多款 Sched-Ext 示例调度器，快速验证环境可用性

# 进入Sched-Ext工具目录
cd linux-6.6/tools/sched_ext
# 编译官方示例调度程序
make -j$(nproc)

编译完成后生成scx_simple、scx_qmap等可执行文件，为极简 FIFO 调度、多级优先级调度示例。

三、实际工程应用场景（300 字精简详解）

在中小型服务器集群算力调度场景中，线上业务分为前端接入进程、后端数据计算进程、日志采集轻量进程三类，原生 CFS 调度无法精准区分算力权重，常出现计算任务被轻量进程抢占资源的问题。借助 Sched-Ext 热插拔特性，运维人员可在业务无停机状态下，动态加载自定义权重调度 BPF 程序，将高负载计算进程划入高优先级 DSQ 队列，优先分配大时间片与独占 CPU 核心；业务低谷期直接卸载自定义调度策略，自动切回 CFS 均衡调度，无需重启集群节点。同时在工业嵌入式网关设备中，现场调试人员可现场热加载实时调度策略优化外设响应时延，调试完成后一键卸载恢复默认调度，彻底解决传统内核调度修改必须停机烧录固件的痛点，兼顾调度灵活性与系统运行稳定性。

四、实战案例：自定义 Sched-Ext 调度器编写 + 动态热插拔加载卸载

4.1 编写极简自定义 Sched-Ext 调度 BPF 代码

新建scx_my_sched.bpf.c，完整可直接编译，实现基础选核、进程入队调度逻辑

// scx_my_sched.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>
#include "sched_ext.bpf.h"

// 自定义调度器名称
#define MY_SCHED_NAME "my_custom_scx"

// 进程唤醒时CPU选择回调
s32 BPF_STRUCT_OPS(my_select_cpu, struct task_struct *p,
                   s32 prev_cpu, u64 wake_flags)
{
    bool direct_insert = false;
    // 调用内核默认选核逻辑
    s32 target_cpu = scx_bpf_select_cpu_dfl(p, prev_cpu, wake_flags, &direct_insert);

    // 空闲CPU直接插入本地队列，跳过入队回调
    if (direct_insert) {
        scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL, SCX_SLICE_DFL, 0);
    }
    return target_cpu;
}

// 进程就绪入队回调
void BPF_STRUCT_OPS(my_enqueue, struct task_struct *p, u64 enq_flags)
{
    // 无法直接入本地队列，则放入全局调度队列
    scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags);
}

// 调度器初始化回调
s32 BPF_STRUCT_OPS_SLEEPABLE(my_sched_init)
{
    bpf_printk("自定义Sched-Ext调度器成功加载\n");
    return 0;
}

// 调度器退出销毁回调
void BPF_STRUCT_OPS(my_sched_exit, struct scx_exit_info *ei)
{
    bpf_printk("自定义Sched-Ext调度器已卸载，退出类型：%d\n", ei->type);
}

// 挂载至内核调度操作结构体
SEC(".struct_ops")
struct sched_ext_ops my_scx_ops = {
    .name       = MY_SCHED_NAME,
    .init       = (void *)my_sched_init,
    .exit       = (void *)my_sched_exit,
    .select_cpu = (void *)my_select_cpu,
    .enqueue    = (void *)my_enqueue,
};

// 声明BPF调度对象
char _license[] SEC("license") = "GPL";

代码作用说明：该调度器复用内核默认 CPU 亲和性选择逻辑，空闲 CPU 进程直接进入本地调度队列，繁忙进程统一放入全局队列，实现轻量级负载均衡调度，同时预留初始化与退出日志打印，方便观测热插拔状态。

4.2 编写编译 Makefile

新建Makefile，一键编译生成可执行调度程序

CC := clang
CFLAGS := -g -O2 -target bpf -D__TARGET_ARCH_x86_64
BPF_OBJ := scx_my_sched.bpf.o
USER_BIN := scx_my_sched

all: $(BPF_OBJ)
	# 编译用户态加载程序
	gcc -o $(USER_BIN) scx_loader.c -lbpf -lelf -lz

$(BPF_OBJ): scx_my_sched.bpf.c
	$(CC) $(CFLAGS) -c $< -o $@

clean:
	rm -f $(BPF_OBJ) $(USER_BIN)

4.3 动态加载调度器（热加载，无需重启）

# 赋予执行权限
chmod +x scx_my_sched
# 后台运行加载自定义Sched-Ext调度器
sudo ./scx_my_sched &

加载生效验证命令

# 查看当前Sched-Ext运行状态
cat /sys/kernel/sched_ext/state
# 查看正在运行的自定义调度器名称
cat /sys/kernel/sched_ext/root/ops
# 查看内核BPF打印日志
sudo dmesg | grep "自定义Sched-Ext"

输出enabled与自定义调度器名称，代表热加载成功，系统所有普通进程已纳入自定义调度管控。

4.4 动态卸载调度器（热卸载，业务不中断）

方式 1：终止调度进程自动卸载
# 查找调度程序进程号
pidof scx_my_sched
# 终止进程，内核自动触发exit回调，卸载调度策略
kill -9 进程ID
方式 2：SysRq 快捷键强制回退卸载

生产环境调度卡死应急卸载方案

# 开启SysRq功能
sudo echo 1 > /proc/sys/kernel/sysrq
# 触发Sched-Ext强制退出，切回CFS调度
sudo echo S > /proc/sysrq-trigger

卸载验证

cat /sys/kernel/sched_ext/state

输出disabled即为卸载完成，所有进程恢复 Linux 原生 CFS 公平调度。

4.5 区分全局调度与局部调度

  1. 全局调度模式：默认加载模式，SCHED_OTHER、SCHED_BATCH、SCHED_IDLE全部由 Sched-Ext 管控；
  2. 局部调度模式：设置SCX_OPS_SWITCH_PARTIAL标志，仅将手动设置为SCHED_EXT策略的进程纳入管控，其余进程保持原生调度。

进程设置为 SCHED_EXT 策略测试代码

#include <stdio.h>
#include <unistd.h>
#include <linux/sched.h>
#include <sys/syscall.h>

int main()
{
    struct sched_attr attr = {0};
    attr.size = sizeof(attr);
    // 设置为EXT调度策略
    attr.sched_policy = SCHED_EXT;
    syscall(SYS_sched_setattr, getpid(), &attr, 0);
    printf("当前进程已加入Sched-Ext自定义调度\n");
    while(1) sleep(1);
    return 0;
}

编译运行后，该进程仅受加载的自定义调度器管控。

五、Sched-Ext 热插拔常见问题与解决方案

Q1：执行加载命令提示 CONFIG_SCHED_CLASS_EXT 未开启

原因：当前运行内核未开启 Sched-Ext 核心配置 解决：重新编译 6.6 以上内核，严格开启CONFIG_SCHED_CLASS_EXT=y，重启切换新内核即可。

Q2：BPF 调度程序加载成功，但 sysfs 状态始终为 disabled

原因：BPF 程序校验失败、回调函数定义不规范、内核 BTF 信息缺失 解决：开启CONFIG_DEBUG_INFO_BTF，使用bpftool prog load排查 BPF 字节码错误，核对sched_ext_ops结构体回调定义与内核版本匹配。

Q3：卸载 Sched-Ext 后部分进程出现卡顿、调度延迟升高

原因：进程 CPU 亲和性被自定义调度器修改，未自动恢复 解决：重启卡顿进程，或执行sudo taskset -c 0-7 进程PID重置进程 CPU 绑定关系。

Q4：高并发场景下加载 Sched-Ext 出现内核软锁死

原因：自定义 BPF 调度回调中存在死循环、无休眠阻塞逻辑 解决：精简 tick、enqueue 回调执行逻辑，避免长时间占用调度锁，内核检测卡死会自动触发回退机制。

Q5：普通用户无法加载 Sched-Ext 调度器

原因：缺少系统权限与 BPF 资源权限 解决：全程使用sudo执行，或配置/etc/security/capability.conf赋予用户CAP_BPF、CAP_SYS_SCHED权限。

六、生产环境实践建议与最佳实践

6.1 调度器热插拔使用规范

  1. 测试优先原则：自定义 Sched-Ext 调度策略必须先在测试机完成 72 小时稳定性压测，再线上热加载；
  2. 灰度切换策略：线上业务优先使用SCX_OPS_SWITCH_PARTIAL局部模式，仅测试少量业务进程，无异常再切换全局调度；
  3. 应急兜底方案：线上加载自定义调度器前，提前熟记 SysRq 强制回退命令，杜绝调度异常导致业务瘫痪。

6.2 性能优化技巧

  1. 精简 BPF 回调函数执行逻辑，select_cpu、enqueue中避免复杂运算，减少调度耗时；
  2. 业务进程与调度 CPU 进行亲和性绑定，减少进程跨 CPU 迁移带来的 DSQ 队列数据同步开销；
  3. 大批量进程调度场景下，合理设置dispatch_max_batch批量分发阈值，提升调度吞吐。

6.3 调试排错最佳流程

  1. 利用dmesg查看 BPF 自定义日志，确认调度器加载与卸载流程是否完整；
  2. 通过ftrace跟踪scx_bpf_enqueue、scx_bpf_select_cpu内核函数调用频次，定位调度卡点；
  3. 使用bpftrace实时抓取进程调度队列入队、出队日志，分析调度时序异常。

6.4 内核二次开发建议

  1. 基于 Sched-Ext 热插拔特性，可自研业务专属优先级调度、IO 敏感进程专属调度、算力分时调度策略；
  2. 切勿修改kernel/sched/ext.c核心框架代码，尽量通过 BPF 用户态程序实现调度逻辑，保证内核原生稳定性；
  3. 撰写学术论文时，可基于热插拔动态切换调度策略，完成不同调度算法性能对比实验，数据真实性更高。

七、全文总结与工程落地延伸

本文系统性讲解了 Linux Sched-Ext 可扩展调度器的底层架构、热插拔动态加载卸载核心原理，从内核配置、BPF 调度代码编写、实操加载卸载、状态观测、异常排查到生产最佳实践形成完整实战体系。

Sched-Ext 热插拔机制彻底打破了传统 Linux 调度策略固化、修改必须重启系统的行业痛点，依托 BPF 轻量化字节码实现调度逻辑灵活定制，搭配自动回退兜底机制，完美适配不间断运行的服务器集群、工业嵌入式设备、边缘计算节点等核心生产场景。

对于技术研发人员而言，吃透该特性不仅能够完成进程调度性能调优、定制化调度策略开发，还能深入理解 Linux 内核调度框架设计思想；对于学术调研与论文撰写，可借助动态热插拔特性快速切换 CFS、Deadline、自定义调度算法，完成多维度调度时延、上下文切换耗时、系统吞吐量对比实验。

后续可深入研究 Sched-Ext 多级 DSQ 优先级队列实现、调度时延精准采样、容器场景下 Sched-Ext 进程分组调度等进阶方向，将动态热插拔调度能力真正落地至实际项目中，最大化发挥 Linux 开源调度体系的可扩展价值。

# linux # 运维 # 服务器 # 自动驾驶 # 操作系统
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

【linux学习】linux工具篇（上）

今天来学习一些linux的基本工具，vim,编译器gcc,g++等，下面进行介绍。一、Linux软件包管理器yum什么是软件包在Linux下安装软件,一个通常的办法是下载到程序的源代码,并进行编译,得到可执行程序.但是这样太麻烦了,于是有些人把一些常用的软件提前编译好,做成软件包(可以理解成windows上的安装程序)放在一个服务器上,通过包管理器可以很方便的获取到这个编译好的软件包,直接进行安装

avatar openEuler 社区

从学习到实操，聊聊MonkeyCode的全场景使用价值

国产模型包含GLM 5.1、Kimi 2.6、DeepSeek，中文理解能力优秀，适配国内开发习惯，注释清晰、代码通俗易懂，适合新手学习、常规项目开发。每日高额免费额度、全模型加持、移动端适配，无论是自学入门、职场提效、副业接单，都十分适配。不用担心本地环境崩溃，每一段代码都能实时运行、智能纠错，AI逐行讲解逻辑，比起单纯看视频学习，实操效率更高，非常适合转行、自学编程的人群。传统编程工具需要下载

avatar openEuler 社区

从LLM到Agent：解密智能体的核心架构与关键技术栈

Agent不仅仅是大模型的一个插件，它是AI操作系统的雏形。通过将“规划、记忆、工具、行动”闭环，Agent让AI从“对话”走向了“做事”。在2026年的今天，我们正处在一个从“Prompt Engineering”向“Agent Engineering”转型的关键节点。理解Agent的架构，意味着掌握了大模型改变世界的钥匙。你认为Agent未来会取代传统的APP吗？或者你正在开发什么样的Agen

avatar openEuler 社区