最近在 6.15.7 上把 sched_ext 重新过了一遍几个回调里最容易被低估的就是init_task。很多人写 BPF 调度器时先去看enqueue、dispatch、run因为那些直接决定任务怎么被选出来、怎么跑但init_task决定了你的调度器能不能正确认识每个任务甚至决定了调度器 attach 后会不会直接崩掉。这篇不聊泛泛的框架介绍直接聚焦 Linux 6.15.7 下 sched_ext 的init_task回调讲清楚它的调用时机、内核侧契约、可运行示例以及我实际调试时踩过的几个坑。你可能已经在 scx 示例里见过ops.init_task ...这种写法但对它背后的调用条件、返回值的含义、和exit_task怎么配合还是含糊。这篇文章就是补这一块的。适合三类人看正在写自定义 BPF 调度器的人、想在调度器里为每个任务维护私有状态的人、以及纯粹想把 sched_ext 生命周期读懂的内核爱好者。1. sched_ext 回调全景里init_task 处于什么位置1.1 不要把 init_task 当成普通“钩子”sched_ext 不是简单的 tracepoint 或者 kprobe它通过 BPF struct_ops 机制把一组调度回调注册进内核的调度子系统。换句话说你写的不是观测代码而是真正的调度路径的一部分。init_task正是这条调度路径上最早出现的回调之一。很多从 eBPF 监控程序转过来的人会有一个错觉回调嘛能有多关键最多就是打印一下。实际不是。在 sched_ext 里init_task的返回值会影响这个任务能不能顺利进入调度器视野它里面做的初始化逻辑直接决定后续enqueue、dispatch能不能拿到正确的任务上下文。所以它不是“额外加的钩子”而更像是每个任务的构造函数。另外有个容易混淆的点内核里有一个全局变量叫init_task它是系统初始化时第一个任务描述符也就是常说的 0 号进程或者 idle 线程而 sched_ext 的ops.init_task是一个回调函数指针针对的是任意任务。两者只是同名别搞混了。我见过有人查init_task时跑去看内核启动流程查了半天才发现方向错了。1.2 init_task 在任务生命周期里的位置一个任务从诞生到离开在 sched_ext 里大致会经历这样一条路径fork 创建新任务普通调度器先接手在合适的时机sched_ext 调用init_task让 BPF 调度器为任务做初始化任务变成可运行进入enqueue被选中执行进入dispatch和run任务退出或停止运行可能走exit_task做资源回收。init_task的作用就是这条路径上的前置条件它先跑后面的enqueue、dispatch才有一个已经初始化好的任务上下文。如果你在enqueue里想读取某个 per-task 的状态字段而这个字段是在init_task里设置的那顺序就非常重要。我个人的理解是把init_task当成一个构造函数把exit_task当成析构函数。所有需要跟任务一一对应的资源都应该在这两个回调里成对处理。只分配不释放时间一长必然出问题。1.3 为什么调度器需要这样一个初始化回调有 CFS、RT 这些内核调度器在前为什么 sched_ext 还要单独搞一个init_task?原因是 BPF 调度器有自己独立的数据结构。内核调度器可以用task_struct自带的那几个调度字段比如prio、se、rt因为它们就在任务结构体里。但 BPF 调度器的状态没法随便塞进task_struct一般要放在 BPF 哈希表或数组里。如果不在init_task阶段把这个状态创建好后续每个回调里都要做“如果没创建就创建”的懒初始化代码会变得又啰嗦又容易在竞争时出错。init_task还承担了把任务和调度器策略绑定起来的职责。比如你要做一个按 cgroup 分组的调度器你需要在任务进入调度路径之前就知道它属于哪个 cgroup如果你要按任务类型区分策略也需要在早期把这个信息算好。这不是enqueue阶段临时能做的因为enqueue的调用频率太高不适合每次做重活。2. 6.15.7 里 init_task 的调用时机与实现机制2.1 它到底是什么时候被调用的最核心的问题BPF 调度器 attach 之后系统中已经存在的几千个任务难道要一个一个立刻调用init_task吗还是说只有新 fork 的任务才调用以 6.15.7 的实际行为看两者都有但方式不是“attach 时一次性全量回调”而是采用了更务实的懒初始化思路。调度器注册成功后已经存在的可运行任务不会在 attach 瞬间全部涌入你的 BPF 回调而是会在它们第一次真正进入 BPF 调度路径之前补上init_task的调用。新 fork 出来的任务也会在进入调度器管辖前触发这个回调。这个设计其实很合理。如果 attach 时系统里有几千个任务一个个同步调用 BPF 回调会拉长 attach 过程而且很多任务可能根本不会被新调度器处理到。懒初始化让开销分散到后续调度事件中也是 BPF 程序可以接受的。不过要注意不同版本的内核在具体实现细节上可能略有差异。比如某些版本可能走了一个批量预初始化路径某些版本则完全是按需触发。所以写代码时不要依赖“attach 结束前所有任务一定都调过 init_task”这种假设应该把init_task写成幂等且可重入的。2.2 回调签名、上下文和返回值约定6.15.7 里sched_ext_ops结构体中的init_task回调语义大致是这样的struct sched_ext_ops { // 其他回调... s32 (*init_task)(struct task_struct *p, struct scx_init_task_args *args); void (*exit_task)(struct task_struct *p, struct scx_exit_task_args *args); };签名里面第一个参数是目标任务本身第二个参数是附加的上下文信息。这里有两个细节很关键第一回调的第一个参数是task_struct *但你拿到的只是一个指针。在 BPF 程序里不能上来就随便解引用它需要按 CO-RE 方式读取字段。这不是init_task特有的限制而是写所有 sched_ext 回调的基本功。第二返回值s32不是让你随便返回的。简单来说返回 0 表示初始化成功任务可以进入后续调度路径返回负数表示初始化失败。失败之后内核侧会进入错误处理流程通常最终会导致调度器进入故障状态并退出。所以你不仅要保证逻辑正确还要保证这个回调尽可能不失败。args里携带什么不同版本会有差别。如果你的调度器需要在init_task阶段获取 cgroup 或其它上下文信息一定要看当前头文件里的定义不要照抄老版本的字段名。我个人建议在init_task里只做那些必须做的初始化复杂的信息查询尽量放到低频路径里去做。2.3 和 exit_task 的配对契约init_task和exit_task是天然的一对。init_task被调用时你可以给任务分配 BPF map entry、设置初始状态、记录调度元数据当任务退出、不再需要被这个调度器管理时exit_task会被调用让你回收这些资源。这里有个很常见的错误只写了init_task不写exit_task。如果每个任务都往一个哈希表里插入一条记录任务退出时不删除这张表会无限膨胀。调试时你可能还会看到系统内存被 BPF map 吃掉一大块重启调度器才恢复。还有一个细节任务可能不会在同一个调度器实例下完成整个生命周期。你在init_task里分配的资源最终不一定在本轮调度器中释放中间可能涉及任务迁移、调度器重启等环节。最稳妥的写法是每次初始化前检查一下是否已经初始化保证重复调用时不会状态错乱exit_task里也做同样的幂等处理。3. 写一个带 init_task 的最小可运行调度器3.1 环境准备与版本确认写代码前先确认你的内核确实支持 sched_ext并且 headers 里包含sched_ext_ops相关定义。6.15.7 肯定没问题但我还是建议你先检查一下内核版本是否高于或等于 6.12因为 sched_ext 是 6.12 合入主线的内核配置里CONFIG_SCHED_CLASS_EXT是否打开系统是否具备 BPF struct_ops 支持bpftool feature可以确认。示例代码我按 6.15.7 的接口习惯写但不同发行版带的头文件可能有细微差别。最保险的做法是直接使用当前内核源码树里的tools/sched_ext示例作为基底把我的init_task片段贴进去。3.2 一个最简单的 init_task 回调下面这段代码不是完整调度器只展示init_task怎么写。核心逻辑是为每个进入调度器的任务记录一次 pid 和 comm并在一个 BPF map 里累计初始化次数。#include scx/common.bpf.h #include vmlinux.h char LICENSE[] SEC(license) GPL; /* 用一个数组 map 记录 init_task 触发的次数 */ struct { __uint(type, BPF_MAP_TYPE_ARRAY); __uint(max_entries, 1); __type(key, u32); __type(value, u64); } init_count_map SEC(.maps); /* 用一个哈希 map 记录每个 task 的初始状态 */ struct { __uint(type, BPF_MAP_TYPE_HASH); __uint(max_entries, 100000); __type(key, pid_t); __type(value, u64); } task_init_state SEC(.maps); static s32 init_task(struct task_struct *p, struct scx_init_task_args *args) { pid_t pid; u32 key 0; u64 *count; u64 state 0; /* 通过 CO-RE 读取目标任务的 pid不要用 bpf_get_current_pid_tgid() */ bpf_core_read(pid, sizeof(pid), p-pid); /* 如果之前已经初始化过直接返回成功保证幂等 */ if (bpf_map_lookup_elem(task_init_state, pid)) return 0; bpf_map_update_elem(task_init_state, pid, state, BPF_ANY); count bpf_map_lookup_elem(init_count_map, key); if (count) { __sync_fetch_and_add(count, 1); } bpf_printk(init_task called for pid%d comm%s, pid, p-comm); return 0; } SEC(struct_ops) struct sched_ext_ops ops { .init_task (void *)init_task, /* 这里需要补上 enqueue、dispatch 等回调完整调度器才能运行 */ };这只截取了核心片段。有几个地方特别注意p-comm是字符数组在上面代码里直接传给bpf_printk是可行的因为bpf_printk会处理字符串。如果你想把它拷贝到自定义缓冲区一定要用bpf_probe_read_kernel_str别用普通字符串拷贝。我用bpf_core_read读p-pid不用bpf_get_current_pid_tgid()。原因在下一节讲但这里先记住init_task回调的运行上下文不一定是目标任务本身current可能是内核线程或者另一个任务。init_count_map的 lookup 和 atomic add 之间并不是严格原子计数器操作示例只是为了看图方便别直接拿去做精确统计。3.3 把回调挂到调度器上并观察触发上面代码的SEC(struct_ops)段声明了sched_ext_ops实例实际编译时需要有一个完整的用户态加载程序。最简单的做法是拿 sched_ext 仓库里的示例调度器例如scx_simple作为骨架把你的回调函数指针替换进去。编译时建议开启-g这样可以保留 BTF 信息和调试符号。加载后通过 tracefs 观察bpf_printk输出cat /sys/kernel/debug/tracing/trace_pipe如果你只想确认 map 计数在涨可以用bpftool map dump查看init_count_map的值。注意刚 attach 时因为懒初始化机制可能看不到大量输出你可以手动执行几个进程或者让系统稍微跑一会儿计数就会明显增加。如果你的调度器同时实现了enqueue或dispatch还可以做一个辅助实验在init_task里故意不设置任何状态然后去enqueue里读取task_init_state你会发现自己可能拿到全 0 或直接找不到记录。这能帮你直观理解“初始化必须先于调度路径”的顺序约束。3.4 从示例到完整调度器要补什么如果只定义init_task而没有其它调度回调内核不会让这个调度器正常跑起来。你至少需要补上一个调度策略实现。最简单的策略可以是一个 FIFOenqueue里把任务放到一个全局队列dispatch里把队首任务弹出来。如果你不想自己从头写队列逻辑就基于 scx 官方示例改。官方示例里有很多已经实现好的链路你只需要把init_task加进去再看一下enqueue、dispatch是否用到了你初始化的字段。这种改法比自己从零搭一个 BPF 调度器稳得多。4. 调试 init_task 时我踩过的几个坑4.1 不要在 init_task 里用 bpf_get_current_pid_tgid()这个坑几乎每个写 sched_ext 的人都会踩一次。直觉上任务初始化回调嘛当前任务不就是目标任务嘛直接bpf_get_current_pid_tgid()取 pid 不就行了实际上不行。bpf_get_current_pid_tgid()返回的是“当前执行 BPF 程序的上下文”的 pid 和 tgid而init_task回调触发时很可能是在内核的某个调度路径或者辅助线程上下文中current并不一定是你要初始化的那个任务。换句话说你以为自己在记 A 任务的 pid实际记的是 B 任务的 pid。所以正确姿势只有一个从回调参数里拿任务信息。代码里尽量用 CO-RE 方式读取p-pid、p-tgid、p-comm。这不仅是“能读到”的问题更是语义正确性的问题。4.2 打印风暴会拖垮系统bpf_printk在调试阶段确实方便但它走 tracefs输出量大的时候会严重影响系统性能甚至让 attach 过程看起来像是卡死了。我遇到过一种情况调度器刚 attach系统里有大量内核线程和用户进程每个任务触发一次init_task每个回调里打印两行。结果就是 trace_pipe 瞬间被刷爆ssh 都开始卡。后来我改成只在 map 里累计计数用bpftool map dump间隔观察问题立刻消失。如果你想保留一些观察能力可以不直接打日志而是把 pid 记录到一段 ring buffer 里只在必要时用用户态程序读取。这样既能看到哪些任务被初始化过又不会过度影响调度路径。4.3 忘了写 exit_task状态表越涨越大我写过一个小实验调度器init_task里往哈希表写了任务状态但exit_task是空的。刚开始没感觉跑了一晚上加一上午那个 BPF map 的条目数涨到了几万。任务早就退出了但状态永远留在表里。这种情况下调度器本身的性能也会下降如果一个新任务恰好复用了旧 pid你会在init_task里查到旧状态如果逻辑没做好幂等就可能用到过期的调度参数。所以我的经验是从写第一版init_task开始就同时把exit_task的空实现放上后续有需要再填内容。这样不会忘。4.4 认为每个任务只会被初始化一次严格意义上一个任务在一个调度器实例内init_task通常不会反复触发但你的调度器可能被卸载再重挂或者任务经历了特殊的迁移路径。这些情况下初始化逻辑可能被执行多次。如果你的初始化逻辑不是幂等的比如每次都给状态加一那多执行几次之后状态就完全不可信了。所以init_task里的逻辑要设计成“不管跑几次结果一致”。最稳妥的方法就是先查询 map 里是否已有该任务的记录有就直接返回 0。4.5 在初始化里做大量计算或复杂查询init_task的调用频率虽然比enqueue低但它仍然处于内核关键路径上。如果你在里面做大量遍历、查询、甚至 sleep会直接影响任务进入可运行状态的效率。我见过一个实现在init_task里对每个任务做一次 cgroup 路径字符串解析结果 attach 之后整个系统的调度延迟明显变大。后来把 cgroup 相关的字符串解析挪到用户态准备阶段内核侧只保存一个枚举值性能开销降了一个量级。记一条原则init_task里只做 O(1) 的轻量初始化把重计算留给用户态或者低频回调。它相当于一个构造函数构造函数越轻系统启动越快。5. 从 init_task 往后看整个调度器生命周期5.1 enqueue 之前到底发生了什么很多调度器把大量逻辑塞在enqueue里但enqueue的上下文很忙不适合做初始判断。正确拆分方式是init_task决定任务的基础元数据设置初始状态enqueue根据当前状态决定任务进入哪个队列dispatch从队列里挑出下一个要执行的任务run任务被选中之后、真正执行之前做最后处理。这样分下来每个回调的职责就很清楚。如果你发现自己在enqueue里频繁判断“这个任务有没有初始化过”说明init_task的使用方式有问题应该把初始化结果前置。5.2 构造和析构要一起设计前面提过init_task和exit_task是构造/析构对。这里再补充一个设计上的细节如果你为每个任务维护了不止一个数据结构建议用一个统一的 per-task 上下文结构体在init_task里只分配一次后续所有回调都从这个结构体里取字段。示例结构体可以长这样struct task_ctx { u64 enqueue_count; u64 dispatch_count; u64 run_count; bool initialized; };init_task里把它初始化并放到 BPF mapenqueue里让enqueue_count加一exit_task里从 map 删除。这种模式非常清晰调试时也容易打印。如果你发现某个任务的enqueue_count还在涨但任务已经退出那就是 map 没有在exit_task里清掉。5.3 对特殊任务的初始化要格外小心不是所有任务都应该被同一个调度器策略对待。内核里有很多特殊任务idle 线程、迁移线程、以及调度器自身可能依赖的内核线程。在init_task里你可以通过p-flags检查任务类型也可以直接看 pid 范围做简单过滤。但千万不要在init_task里假设所有任务都是普通用户进程。比如某些内核线程的mm为空如果你在初始化时读取task_struct-mm相关字段要小心空指针。我的习惯是init_task里对一些明显特殊的标志位做 early return避免后续逻辑出错。比如if (p-flags PF_KTHREAD) return 0;这行代码的作用不是歧视内核线程而是告诉你的初始化逻辑内核线程可能走另一套简化路径。很多通用调度器会直接不管这类线程让它们在缺省路径上运行。5.4 后续场景扩展init_task只是入口它后面可以接很多东西。比如你想做一个按优先级分类的调度器可以在init_task里解析任务的优先级字段写成 map 中的一个数值想在任务进入调度器时就绑定某个固定的 CPU 集合也可以在这个阶段记录。再往后如果要支持 task migration 和 hotplug 场景还需要补充对应的回调逻辑。这些扩展的共同点是所有信息都最好在init_task阶段算好后续回调只做增量处理。我后来写新调度器时都会先画一张表每个任务有哪些字段这些字段在哪个回调里被初始化、读取、更新、销毁。表格理清了整个调度器逻辑就不会乱。另外一个很实用的技巧是把init_task触发次数和系统真实任务数做对比。如果你发现 map 里的任务数和系统ps看到的任务数差距很大那说明有些任务没走你的初始化路径要么是特殊任务被过滤了要么是你的调度器没有管理这些任务要么是懒初始化还没轮到它们。这种对比可以作为调度器健康度的一个快速检查手段。最后分享一个自己的习惯写 sched_ext 调度器时我会在init_task里放一个极简的计数 map这个 map 不清理专门用来统计“这个调度器实例总共见过多少任务”。它不影响逻辑但每次调试时都能用bpftool map dump快速确认调度器是否真的在工作也比看日志直观得多。你可以试试这个做法。