Paper摘要:Linux内核调度器的LLM Agent框架

https://arxiv.org/pdf/2509.01245

这篇论文的野心：

让操作系统不再只靠人类写死的调度策略，而是让 AI 成为“懂业务语义的调度专家”。

论文提出了一个非常激进但克制的方向：Agentic OS（代理化操作系统） ——用 LLM Agent 作为 控制平面，自动生成、验证、部署 Linux 调度策略。

但要强调一句：

❗它不是“让 LLM 进内核跑推理”，❗而是“让 LLM 生成可执行、可验证的内核调度策略”。

论文核心问题：调度器语义鸿沟

传统 Linux 调度器（如 CFS/EEVDF）：

• 策略是静态的、一刀切；

• 它们无法理解“应用的真实意图/性能需求”；

• 导致在不同工作负载上表现不理想（尾延迟高、吞吐不稳定等）。

所以核心问题是：

内核策略缺乏对应用语义（app-level intent）的理解，而这正是优化调度性能的关键。

论文提出 SchedCP 框架：用 LLM agent（大型语言模型） 来理解工作负载语义、自动生成调度策略。

其架构关键：控制平面与执行平面分离。

控制平面 vs 执行平面

• 控制平面（用户态）

• LLM Agent

• 分析 workload

• 生成调度策略

• 执行平面（内核态）

• 只运行 已验证的 eBPF 调度逻辑

• 不跑 AI，不做推理

AI 负责“想”，内核负责“跑”。

SchedCP 的三个核心部件：

🧠 ① Workload Analysis Engine

• 负责收集和分析系统行为/负载特征；

• 不是一堆原始数据，而是构建语义化的“工作负载 profile”。

📦 ② Scheduler Policy Repository

• 存储AI 生成过的调度策略及其元数据（描述、效果指标等）；

• 能用于查询、重用、组合已有策略；

🛡 ③ Execution Verifier

• 用静态/动态分析验证 AI 生成的策略安全性；

• 内核态最危险的是错误代码 → verifier 过滤掉 unsafe 配置；

论文强调：

使用 LLM 不是让它直接写内核代码，而是 解构 Scheduler 优化问题：

1. Goal-inference：理解“优化目标是什么”

2. Policy-synthesis：把目标转成可执行调度策略（eBPF 程序）

这两阶段分离非常重要：

• Goal-inference 是语义理解；

• Policy-synthesis 不直接把 NN 推理跑在内核路径中；

• 而是输出经验证、可执行的调度策略。

sched-agent：多智能体系统实现

SchedCP 不是一个单一的 LLM，而是一个多 agent 协作体系：

sched-agent 的一次完整“工作周期”

eBPF 用法 & Kernel Inteface

论文中很清晰强调：

不是让 LLM 直接在内核运行推理而是把生成的 scheduler 逻辑输出成 eBPF 调度程序，然后安全地载入内核调度扩展 sched_ext。

论文做法是 LLM 生成内核策略，然后经过验证才运行。

实验亮点（定量数据）

论文给出了初步评估：

这说明：

• AI 生成调度策略在某些场景下真的有意义；

• 简单策略（静态调参）无法达到这种效果。