如何修改Linux scheduler实现应用用户态与内核态代码在指定CPU运行

首先明确：原生Linux没有提供直接实现该需求的公开接口，目前可通过两类技术路径实现，均仅适用于调试、研究场景，不具备生产环境实用性。

方案1：eBPF无内核修改实现（支持内核版本5.10及以上） #

• 实现逻辑：利用eBPF tracepoint捕获进程的用户态/内核态切换时机，动态修改进程的CPU亲和性
• 操作步骤：
  1. 预先定义目标进程PID、用户态绑定CPU编号cpu_user、内核态绑定CPU编号cpu_kernel
  2. 挂载三个trace探测点：raw_syscalls:sys_enter（进程进入系统调用，即切入内核态）、raw_syscalls:sys_exit（进程退出系统调用，即切回用户态）、sched:sched_switch（处理进程调度场景的状态判断）
  3. 当捕获到目标进程触发sys_enter事件时，调用sched_setaffinity系统调用将该进程的CPU亲和性掩码设置为仅包含cpu_kernel
  4. 当捕获到目标进程触发sys_exit事件时，调用sched_setaffinity将亲和性掩码修改为仅包含cpu_user
• 缺点：系统调用跟踪的开销较高，部分内核态陷入（如缺页异常、中断触发的内核态执行）无法被syscall trace点覆盖，会出现部分内核态代码仍运行在用户态绑定CPU的情况。

方案2：内核调度器自定义修改实现 #

• 实现逻辑：在内核中为进程新增分运行态的CPU亲和性约束，调度器根据进程当前运行态选择对应的CPU亲和性做调度决策
• 核心修改点：
  1. 在include/linux/sched.h的task_struct结构体中新增两个cpumask字段：user_allowed_cpus、kernel_allowed_cpus，分别存储用户态、内核态的允许运行CPU集合
  2. 新增自定义系统调用，提供用户态配置指定进程的两类亲和性掩码的入口
  3. 修改调度器核心的CPU选择逻辑，在为进程选择运行CPU前，先判断进程当前的运行上下文（用户态/内核态），匹配对应的亲和性掩码作为调度约束
  4. 补充异常陷入、中断上下文、内核线程等特殊场景的状态判断逻辑，避免调度崩溃
• 缺点：需要定制编译内核，实现复杂度较高，需要处理大量边缘场景的调度异常问题。

补充说明：两类方案都无法做到100%的状态和CPU绑定完全匹配，比如进程在内核态运行时被抢占调度，再次调度时如果亲和性还未完成更新，会出现短暂的不符合预期的运行情况，可根据研究的精度要求调整调度判断的优先级。

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