Linux sched_core核心调度cookie匹配与强制idlesched_core是CONFIG_SCHED_CORE引入的SMT同步调度机制解决超线程环境下同核两个硬件线程执行不同trust domain任务的侧信道安全问题。每个task_struct携带一个unsigned long cookiecore_cookie通过prctl(PR_SET_CORE_SCHED_CTX)或cgroup的cpu.core_tag接口设置。核心调度决策的核心约束是同一个物理核心上的两个硬件线程CPU必须同时运行cookie相同的任务否则其中一个线程必须强制idle。cstruct task_struct {#ifdef CONFIG_SCHED_COREunsigned long core_cookie; /* 核心调度cookie */#endif};struct rq {#ifdef CONFIG_SCHED_COREunsigned int core_enabled; /* 该CPU是否开启了核心调度 */unsigned int core_forceidle; /* 是否处于强制idle状态 */unsigned int core_forceidle_occupation;struct cpumask *core_pick_mask; /* 已挑选的任务集合 */#endif};核心调度的任务选择入口在__schedule()的pick_next_task()中。标准pick_next_task经过stop_sched_class - idle_sched_class - ... - fair_sched_class的优先级遍历在sched_core模式下被替换为sched_core_pick_next_task()。该函数为同一个物理核心上的每个CPU选择任务时强制校验cookie匹配约束。c#ifdef CONFIG_SCHED_COREstatic struct task_struct *sched_core_pick_next_task(struct rq *rq){struct task_struct *next, *p;struct rq *core_rq;int cpu, core_cpu cpu_of(rq);if (!rq-core_enabled)return pick_next_task(rq);core_rq rq-core_rq; /* 指向同核master rq */if (rq ! core_rq)return core_rq-core_pick_task; /* 从伙伴CPU的pick结果获取 *//* master CPU负责为整个核心做cookie匹配 */for_each_cpu_and(cpu, cpu_smt_mask(core_cpu), cpu_online_mask) {struct rq *sibling_rq cpu_rq(cpu);struct task_struct *sibling_curr sibling_rq-curr;/* 优先选择cookie匹配的任务 */next pick_next_task(sibling_rq);if (next next-core_cookie ! sibling_curr-core_cookie) {/* cookie不匹配查找匹配cookie的任务 */for_each_class(class) {p class-pick_task(sibling_rq);if (p p-core_cookie sibling_curr-core_cookie) {next p;break;}}}if (!next || next-core_cookie ! core_rq-core_pick_cookie) {/* 找不到匹配cookie的任务强制idle */next idle_sched_class.pick_task(sibling_rq);sibling_rq-core_forceidle 1;}__set_bit(cpu, core_rq-core_pick_mask);core_rq-core_pick_task next;}return core_rq-core_pick_task;}sched_core强制idle的触发条件是一个CPU选择了某个cookie的任务但核心上其他CPU在各自runqueue中都找不到相同cookie的可运行任务。此时pick_result中的core_forceidle被置位。强制idle状态下当前CPU的实际C-state不会进入深睡眠因为核心上的另一个线程还在运行共享L1 cacheidle thread通过play_dead或mwait的c1e浅睡眠轮询等待cookie匹配的任务到达。c/** sched_core的核心选择逻辑——pick_task迭代所有调度类* 返回与给定cookie匹配的任务找不到则返回NULL*/for_each_class(class) {p class-pick_task(rq);if (p (!cookie || p-core_cookie cookie)) {if (cookie)cookie_found true;next p;break;}}/* 如果找不到匹配cookie的任务强制idle */if (cookie !cookie_found) {rq-core_forceidle 1;next idle_sched_class.pick_task(rq);}cookie匹配的粒度是per-task。当任务通过execve()执行新程序时core_cookie不会被清除——它继承自父进程的prctl设置。但set_user()或seccomp事件可能通过security_task_alloc()钩子重置cookie。一个常见竞态是核心上的CPU0持有cookie A的任务正在运行CPU1的任务完成IO后wakeup但其cookie为B。此时CPU1在scheduler_tick的resched路径中检查到core力core_forceidle标记选择idle线程。但CPU1的__schedule()需要等待CPU0先完成当前调度周期——因为sched_core要求核心上所有CPU的pick_task在同一个rq-lock临界区内进行。core scheduler的deactivation路径也涉及cookie检查。当任务调用deactivate_task()如退出或阻塞时如果该任务是核心上最后一个携带特定cookie的任务则核心上所有CPU必须被重新pick_task——否则另一个CPU可能仍然拿着该cookie的idle强制并在等待一个已退出的任务。dequeue_task中通过sched_core_dequeue()检查是否需要触发core re-pickcstatic inline void sched_core_dequeue(struct rq *rq, struct task_struct *p){if (!sched_core_enabled(rq))return;/** 如果该任务是当前核心上该cookie的唯一任务* 标记core resched让所有CPU重新pick*/if (p-core_cookie task_on_rq_queued(p)) {struct task_struct *tmp;bool last true;for_each_online_cpu(cpu) {if (cpu cpu_of(rq))continue;tmp cpu_rq(cpu)-curr;if (tmp-core_cookie p-core_cookie task_on_rq_queued(tmp)) {last false;break;}}if (last || rq-core_forceidle) {/* 唤醒所有SMT兄弟CPU重新选择 */smt_mask cpu_smt_mask(cpu_of(rq));for_each_cpu_and(i, smt_mask, cpu_online_mask)resched_curr(cpu_rq(i));}}}sched_core的migration偏移处理存在一个显著性能折衷。当任务从cookie A的CPU migrate到cookie B的CPU时通过load balance它必须等待核心上其他所有CPU的当前任务完成——因为pick_next_task时无法在同一核心上混合不同cookie。社区解决方向是引入core-wide wakeup即wakeup路径检测到目标核心上正在运行不同cookie的任务时不立即唤醒而延迟到核心空闲。这通过TTWU_QUEUED - try_steal_cookie机制实现但仍处于experimental状态。另一个边界条件涉及PI优先级继承。持有mutex的任务cookie为A但被cookie B的高优先级任务等待时核心调度无法直接进行——因为mutex unlock发生在不同cookie的上下文。sched_core通过core_waiters计数器追踪当核心上等待锁的线程与持有者cookie不同时强制idle策略不应生效任务必须运行才能释放锁否则会导致ABBA死锁。
