AURA — 面向 openEuler 的自适应资源管控 Agent

AURA（Adaptive Userspace Resource-control Agent）把 Linux 的 CPU 调度决策从固定策略变成一个可观测、可干预、可回滚的自主控制过程。

系统由自研 sched_ext 用户态调度器 scx_aura 执行策略，由 aurad 完成 workload 感知、决策、安全校验与执行，并通过声明式 Skills 与 MCP 工具接口对外扩展。所有高风险动作强制经过白名单、参数校验、快照、金丝雀验证、自动回滚与审计。

第三届中国研究生操作系统开源创新大赛 · 系统创新赛道 · 社区赛题目标平台：openEuler 24.03-LTS-SP4（x86_64 已完成实机验证）

1. 为什么需要自适应调度

我们在同一台 openEuler 虚拟机上对四个调度器做了完整对照实验，得到一个明确结论： 不存在全能调度器。

负载	表现最好的调度器	相对 EEVDF
schbench 请求尾延迟	`scx_aura`	+45.77%
schbench 唤醒延迟	`scx_bpfland`	+45.78%
Redis QPS / 尾延迟	`scx_aura`	+56.91% / +31.01%
llama.cpp CPU 推理吞吐	`scx_bpfland`	+14.36%
Linux 内核编译耗时	`scx_bpfland`	+4.92%

scx_rustland 与 scx_bpfland 把唤醒延迟压到 EEVDF 的一半，代价是 schbench 请求 P99 恶化近 4 倍、吞吐下降 42%。反过来，专为吞吐优化的策略在延迟敏感负载上同样吃亏。

固定选择任何一个调度器，都会在另一类负载上付出代价。这正是 AURA 的立足点： 由 Agent 感知当前负载特征，在策略与调度器之间做出选择，并对每次变更负责。

2. 系统架构

┌─ 感知 ────────────────────────────────────────────────┐
│ PSI · procfs · cgroup v2 · scx_stats · eBPF CO-RE hook │
└───────────────────────┬───────────────────────────────┘
                        ↓ WorkloadProfile
┌─ 决策（双时间尺度）───────────────────────────────────┐
│ 快路径：Reflex 规则引擎（毫秒级，投票 + 冷却防抖）      │
│ 慢路径：LLM 规划（DeepSeek，仅在快路径无解时介入）      │
│ 复用层：策略仓库最近邻检索 + 指令缓存                  │
└───────────────────────┬───────────────────────────────┘
                        ↓ ActionProposal
┌─ 安全流水线（强制，不可绕过）─────────────────────────┐
│ 工具白名单 → 参数范围校验 → 后端快照 → 执行            │
│ → 金丝雀指标比对 → 提交 或 自动回滚                    │
│ → 连续 3 次失败熔断 10 分钟 → SQLite 审计              │
└───────────────────────┬───────────────────────────────┘
                        ↓
┌─ 执行 ────────────────────────────────────────────────┐
│ scx_aura（fair / interactive / batch / quota 热切换）   │
│ cgroup v2 权重与配额 · 专家调度器切换                  │
└───────────────────────────────────────────────────────┘

四类协作角色

角色	职责
Observation	采集指标，产出 workload 画像与置信度
Planning	按画像选择策略：规则命中则走快路径，否则调用 LLM 或复用历史方案
Execution	经安全流水线提交动作，失败即回滚
Learning	记录动作前后指标增益，写入策略仓库供后续检索复用

关键设计取舍

LLM 不进入调度快路径。 慢路径只产出「提案」，且必须通过与规则路径完全相同的校验器。模型不能引入新工具、越过参数范围，也不能生成并加载任意 BPF 代码。这样既获得自然语言目标到调度动作的映射能力，又不把不确定性放进内核路径。

决策来源多样，校验路径唯一收口。 Reflex、LLM、策略仓库三条来源产生的提案，都汇聚到同一个 ActionValidator 与 SafetyPipeline。新增决策来源不需要新增安全代码。

能力通过声明式 Skill 扩展。 一个 Skill 用 YAML 声明它感知哪些指标、用哪条决策路径、允许调用哪些工具、参数上下界、金丝雀指标与熔断阈值。新增能力不改核心代码。

3. 已实现能力

CPU 调度（`scx_aura`）

基于 scx_rustland_core 的用户态调度器，BPF 侧调度骨架来自上游，本项目实现其上的策略决策层与运行时控制面：

策略	选取逻辑	适用
`fair`	最小 vruntime	通用、混部
`interactive`	deadline 减去唤醒率补偿，延迟敏感类加权	在线服务
`batch`	最长累计执行时间优先	批处理、编译
`quota`	按 cgroup 归一化用量选取欠额者	多租户隔离

任务在入队时按执行时长、唤醒率与 cgroup 归属被分类为 interactive / batch / latency_critical，供各策略打分。策略与时间片支持毫秒级热更新，无需重启调度器。

感知

系统级与 cgroup 级 PSI（/proc/pressure/cpu、cpu.pressure）
CPU 利用率、上下文切换速率、负载（/proc/stat、/proc/loadavg）
scx 调度器运行时统计（分类计数、入队/派发量）
eBPF CO-RE per-cgroup CPU runtime hook（raw_tp/sched_switch）
应用侧指标（如 P99）经 /run/aura/app-metrics.json 注入

标准化接口

MCP：16 个白名单工具，协议握手实机通过
Skills：cpu-sched、cgroup-qos 为完整实现；network-policy、 security-policy 为扩展模板（template: true，已在页面与配置中如实标注）
eBPF 扩展：cgroup runtime hook 为完整实现（.bpf.c + 用户态消费程序 + Makefile）；XDP 包计数与 execve 审计为可编译的扩展模板

安全

机制	实现
工具白名单	MCP 层、Skill 声明层、校验器三重收口
参数范围校验	按 Skill 声明的上下界校验；cgroup 路径拒绝逃逸与 `system.slice`
快照 / 回滚	执行前读取真实调度器与 cgroup 状态，失败即写回
金丝雀验证	对比关键指标，超出容忍比例即回滚
熔断	连续 3 次回滚后停止该 Skill 10 分钟
审计	提案与结果全量落盘 SQLite

4. 控制台

控制台围绕真实使用流程组织，数据全部来自运行中的系统或归档证据，不含静态示意图。

http://<虚拟机IP>:8080

视图	内容
控制台	自主循环状态、实时 workload、Agent 当前判断、安全执行链、动作流
调度任务	用自然语言描述业务目标与安全边界，由 Agent 自主选择策略
能力接口	实际加载的 Agent 角色、Skills、MCP 工具与 eBPF hook
安全与审计	各 Skill 熔断器状态与动作时间线
实验结果	调度器 × 负载增益矩阵、正式矩阵数据、原始证据路径
成果展示	适合答辩的 sched_ext ops、画像、闭环视图

使用者不需要理解 fair/interactive/batch/quota —— 这些是 Agent 的执行手段，不是产品输入。在「调度任务」中描述目标（例如「优先保障在线服务 P99，批处理至少保留 20% CPU，P99 恶化超 15% 自动回滚」），Agent 会在下一周期接管。

5. 实测结果

测试环境：openEuler 24.03-LTS-SP4，6.6.0-...oe2403sp4-aura 内核， 8 vCPU / 8 GiB 虚拟机。同一台机器顺序测试，所有调度器均为 1 次预热 + 5 次正式重复，报告 mean ± sample stddev。

统计显著的优势项

7 项核心指标在 Welch t 检验（n=5）下显著优于默认 EEVDF：

场景	指标	EEVDF	scx_aura	相对增益
schbench	Request P99 (µs)	22828.8 ± 1389.3	12380.8 ± 1495.2	+45.77%
schbench	Wakeup P99 (µs)	5572.8 ± 281.6	4306.4 ± 221.5	+22.72%
Redis	QPS	954869 ± 281442	1498320 ± 92032	+56.91%
Redis	P50 (ms)	0.641 ± 0.168	0.402 ± 0.019	+37.22%
Redis	P99 (ms)	1.589 ± 0.379	1.097 ± 0.080	+31.01%
llama.cpp	生成吞吐 (tokens/s)	4.97 ± 0.24	5.45 ± 0.12	+9.80%
llama.cpp	最低吞吐 (tokens/s)	4.74 ± 0.32	5.26 ± 0.13	+10.97%

Redis 基线的标准差偏大（EEVDF QPS 变异系数约 29%），该轮测试环境噪声高于其他场景；scx_aura 在同轮的变异系数为 6%，增益方向明确但绝对幅度应结合方差解读。

与 EEVDF 统计持平的项

以下两项虽为正向，但在 n=5 下 Welch t 检验不显著，如实标注为持平而非提升：

场景	指标	EEVDF	scx_aura	差异
schbench	Average RPS	2102.6 ± 81.9	2137.3 ± 95.9	+1.65%（不显著）
内核编译	耗时 (s)	412.74 ± 12.00	405.91 ± 8.08	+1.66%（不显著）

已知短板

满核混部：8 vCPU 全饱和的 Redis + 内核编译混部场景下，scx_aura 的 QPS 仍落后 EEVDF 约 13%。诊断结论是瓶颈来自高频用户态调度往返；增大时间片到 10000µs 可将 P99 改善至优于 EEVDF 2.8%，但吞吐差距未消除。该场景的历史矩阵因未固定时间片、且 quota 用量账本跨样本继承，已判定为配置异常并从正式结论中隔离，页面保留原始证据但不计入摘要。
单项极值：scx_bpfland 在唤醒延迟、推理吞吐与编译耗时上优于 scx_aura。 AURA 的定位不是在单一负载上击败所有专家调度器，而是在负载变化时选对策略。

关于测试口径

Redis 与混部两个场景存在两套矩阵，口径不同，页面与本文均分别标注：

策略预设矩阵：由测试脚本预设策略参数（interactive/750µs），用于验证 scx_aura 在给定参数下的性能上限。上表 Redis 数据来自该矩阵。
Agent 自主矩阵（bench/scenarios/*-autonomous.yaml）：aurad 全程运行，由 Agent 自行感知并决策，每个样本记录其实际选择的策略（aura_decided_policy）。这是「自主控制」的直接证据。

两者不混用：自主场景在参数层面拒绝与预设策略共存，由测试保证。

6. 快速开始

已部署的比赛虚拟机

sudo systemctl enable --now \
  scx-aura aura-cgroup-agent aurad aura-mcp aura-console
sudo bash /opt/aura/deploy/verify-stack.sh

验收通过时应看到 11 行 [PASS]，并以 sched_ext_state=enabled、 sched_ext_ops=aura_...、failures=0 结束。随后打开 http://<虚拟机IP>:8080。

一条命令完整演示

sudo bash /opt/aura/deploy/demo.sh          # 需要外网调用 DeepSeek
sudo bash /opt/aura/deploy/demo.sh --offline # 无外网

依次完成：服务启动 → 11 项验收 → 策略热更新与恢复 → MCP 握手 → 调度器切换与内核安全回退 → 真实 CPU 推理 → LLM 生成建议（不执行）→ 输出控制台地址。异常退出时会自动恢复 scx_aura。

从全新 openEuler 环境部署

cd /path/to/aura
sudo bash deploy/setup-runtime.sh --install-deps

若官方内核未启用 sched_ext，用正式签名 source RPM 构建独立 -aura 内核（保留原内核与 rescue 启动项）：

sudo bash deploy/build-kernel-official.sh --source-rpm <kernel-src.rpm> --install
sudo bash deploy/enable-cgroup-v2.sh
sudo bash deploy/rebuild-kernel-syscall-kfuncs.sh
sudo reboot

内核补丁、上游提交与 SHA256 记录见 /var/log/aura/kernel-build-manifest.txt 与 docs/dependency-provenance.md。

仅预览界面（无需虚拟机）

$env:PYTHONPATH = "src"
python -m uvicorn aura.console:create_app --factory --port 8090

7. 复现实验

# 准备固定版本 workload
sudo bash deploy/prepare-benchmark-workloads.sh
sudo bash deploy/prepare-llama-workload.sh

# 四调度器正式矩阵（1 次预热 + 5 次重复，约 5 小时）
sudo bash deploy/run-technical-matrices.sh

# Agent 自主决策矩阵
sudo bash deploy/run-autonomous-matrices.sh

# 单独运行某个场景
sudo env AURA_BENCH_SCENARIO=bench/scenarios/redis.yaml \
         AURA_ARTIFACT_ROOT=artifacts/redis-rerun \
         bash deploy/run-benchmark-matrix.sh

# 由归档 CSV 重新生成控制台展示数据
PYTHONPATH=src python -m aura.bench.dashboard

展示数据由归档 CSV 统一计算增益方向与统计量，不经人工抄录。

8. 项目结构

src/aura/              Agent 编排、感知、画像、决策、安全、MCP、控制台、基准
├── agent.py           四角色编排与控制循环
├── perception.py      PSI / procfs / cgroup 采集
├── profile.py         workload 画像
├── reflex.py          规则快路径
├── llm.py             LLM 慢路径（DeepSeek 兼容）
├── repository.py      策略仓库与相似度检索
├── safety.py          校验、快照、金丝雀、回滚、熔断
├── tools.py           MCP 工具白名单
└── backends/          mock 与真实 Unix 后端
scheds/scx_aura/       自研用户态调度器（四策略 + 控制面）
skills/                cpu-sched、cgroup-qos、network、security
ebpf/                  cgroup runtime CO-RE hook 与扩展模板
bench/scenarios/       可复现基准场景定义
deploy/                内核构建、运行时、systemd、演示与基准脚本
artifacts/             正式矩阵原始 JSON、汇总 CSV 与门禁日志
console/static/        控制台前端
tests/                 39 项自动化测试
docs/                  环境验证、依赖来源与验证报告

9. 赛题要求对照

要求	实现	状态
用户态调度资源管控 Agent 框架	`scx_aura` + `aurad`，实机运行	完成
标准化 Tools / Skills 接口	MCP 16 工具、4 类声明式 Skills	完成
感知 workload	PSI / procfs / cgroup v2 / scx_stats / eBPF	完成
基于 sched_ext 调整 CPU 策略	调度器切换、策略与参数热更新	完成
集成 scx 优化性能	四调度器实机对照，7 项指标显著优于 EEVDF	完成
eBPF 作为 hook 扩展	cgroup hook 完整实现，network/security 为模板	完成
性能对比与可复现环境	正式矩阵 + 自动化脚本 + 原始证据归档	完成
SP4 编译运行测试	x86_64 正式源码构建，11/11 验收通过	x86_64 完成

10. 质量与工程约束

测试：39 项 Python 测试、5 项 Rust 测试，覆盖越界拒绝、路径逃逸、金丝雀降级回滚、熔断触发、LLM 越权等失败路径，而非仅快乐路径
静态检查：ruff、cargo fmt --check、cargo clippy -D warnings 全通过
CI：GitHub Actions 每次推送运行上述全部检查
数据纪律：正式结果至少 5 次重复并报告标准差；单次门禁数据不包装成正式矩阵；统计不显著的差异如实标注为持平
密钥：仅保存于 /etc/aura/deepseek.key，不进入仓库、日志与命令历史
依赖：上游 scx 组件锁定版本与提交，保留许可证，自研与二开边界单独记录

11. 尚未完成

满核混部场景的用户态快路径优化，以及修复后的同轮正式复测
aarch64 平台复测（赛题鼓励项，非硬性要求）
消融实验：量化每个组件（规则 / LLM / 策略仓库）的独立贡献

参考

sched-ext/scx
Towards Agentic OS: An LLM Agent Framework for Linux Schedulers
Mixture-of-Schedulers: An Adaptive Scheduling Agent as a Learned Router for Expert Policies

更多材料：方案设计 · 验证报告 · 落地状态 · 依赖来源