KernAdapt

KernAdapt 是面向混合负载的自适应内核资源管控 Agent。控制面是系统核心：根据应用吞吐、延迟、资源竞争和用户目标选择内核动作，检查约束后执行，再依据实际效果保留调整或恢复原配置。LockCausal 与 FlowCausal 分别提供面向锁竞争和工具工作流的专用调度机制。

**项目说明书**：完整介绍研究路线、系统架构、核心机制、实现和实验结果。

研究论文

论文	研究内容
KernAdapt	预测资源配置的效果，选择方案并验证执行结果。
LockCausal	锁交接前后的调度；多平台性能与机制验证。已投稿 EuroSys 2027。
FlowCausal	工具返回关系与会话公平调度；真实工具任务和依赖变化实验。计划投稿 OSDI 2027。

LockCausal 补充附录

KernAdapt 控制面

控制面将运行状态、用户目标和资源约束转化为动作方案（ActionPlan）。方案描述调度策略、CPU 放置、时间片、抢占、配额与权重等设置；系统预测这些设置对吞吐、尾延迟和后台进度的影响，再决定是否执行。

KernAdapt 控制面架构

决策与执行

模块	职责
ProfileBuilder	汇总应用指标、CPU 压力、锁等待和资源状态，识别当前运行条件。
PolicyAgent	结合用户目标、动作效果预测和已有执行记录，形成候选方案。
GuardAgent	检查动作参数、权限、资源预算、适用条件和恢复方式。
ExecutorAgent	保存当前配置，限定作用范围与运行时长，实施调整并处理超时和异常恢复。
CriticAgent	对比实测吞吐、延迟与后台进度，判断目标是否达成、约束是否满足，并分析失败原因。
CuratorAgent	保存经过验证的结果及失败记录，更新可供后续决策使用的案例。

运行时保存每一步的输入、决策和结果，限制任务执行时间，并支持恢复和重放。模型提出方案，执行模块检查权限并实施调整。

如何选择资源配置

预测配置效果：根据动作参数，预测吞吐、延迟和后台进度，并参考相似实验中相对 Linux 的收益，评估未完整试过的参数组合。
比较候选方案：按照用户对响应、吞吐和后台任务的要求，比较各方案的预期效果。
决定是否执行：同时评估候选比较和最终选择的风险。数据不足时保持 Linux 默认调度；执行后测量效果，未满足约束时恢复原配置。

控制面实验

实验使用 32 个 AMD EPYC 9654 虚拟 CPU、Linux 7.0.0-29，覆盖 schbench、futex、MariaDB、RocksDB 和 CPU 推理负载。

评估内容	实验设置	结果
组合动作预测	560 个实验组、2,800 次动作执行；分别留出 8 个完整动作组合	平均 regret 0.04357，比因子化 GBDT 低 30.95%，比 pMVX 式检索低 35.36%。
决策与执行实验	30 轮、600 次决策	147 次执行调整，其中 114 次取得正收益（77.55%）；453 次保留 Linux。全部决策的平均效用增益为 0.01398。
执行风险	147 次实际执行	2 次至少一项约束未满足，0 次严重退化；对应的 90% 单侧风险上界为 3.58% 和 1.55%。

regret 衡量所选动作与该组实验中观测到的最优动作之间的效用差，越低越好。两组实验的模型与策略在评测期间保持不变；总体效用的 95% 置信区间为 **[0.01094, 0.01694]**。

控制面论文 · 控制面源码 · 实验汇总 · 运行与测试

项目材料

内容	入口
总体设计、关键技术和完整实验	项目说明书
三项主要创新及验证依据	项目创新说明
研究工作与主要贡献	成员分工及主要贡献说明
Codex、第三方代码与许可证	工具使用说明
测试协议、逐轮数据与验证方法	tests/README.md
可运行演示	demo/README.md
决赛答辩材料	presentation/
原创承诺书	作品原创承诺书.pdf

README.md
src/                     控制平面、机制、分析及策略契约源码
  agent/  analysis/  lockcausal/  flowcausal/  skills/
docs/                    四份必交 PDF、三篇论文及附录、构建说明
  项目说明书.pdf
  LockCausal.pdf  FlowCausal.pdf  KernAdapt.pdf
tests/                   实验记录、逐轮数据、结果核算和验证记录
demo/                    无需特权或 API 密钥的可运行控制面演示
presentation/            决赛现场演示PPT.pdf
作品原创承诺书.pdf
scripts/                 构建、测试和检查入口
results/                 本地运行输出（不纳入提交）

应用场景与主要功能

混合负载资源管控：KernAdapt 根据运行状态和用户目标选择资源配置，完成约束检查、执行验证与异常恢复。
数据库与锁竞争：LockCausal 记录等待者、持锁者和最近运行的 CPU，分别调整持锁者的运行时间与唤醒线程的执行位置。
代码智能体、CI 与沙箱：FlowCausal 确认当前工具正在等待的进程，在会话额度内安排它提前运行。

代码入口：控制平面、LockCausal、FlowCausal。

系统环境

LockCausal 已在 openEuler 24.03-LTS ARM64 完成适配和性能实验。论文覆盖双路 Ampere Altra Max、Linux 6.17、MariaDB 10.6.27，并扩展到 x86、RISC-V 和 VMware。各平台配置与实验结果见 LockCausal 论文及测试材料。

普通 Linux 环境可执行控制面测试与演示。真实调度器加载需要兼容的 BTF/sched_ext 内核和管理权限。

依赖要求与安装

基础验证需要 Python 3.10+、Make、C 编译器和 POSIX/Linux 环境，核心控制面使用 Python 标准库，无需 pip install 或模型密钥。

内核机制构建另外依赖完整的匹配 Linux 源码、Clang/LLVM、bpftool、libbpf、libelf 和 zlib；可选 LangGraph 和绘图依赖分开安装。详细步骤见构建与运行。

安装采用源码目录运行：取得本仓库后进入根目录，执行下列构建命令；Python 控制平面无需系统级安装。调度器二进制目录通过 KERNADAPT_SCX_BIN_DIR 配置。

构建方法

make build

检查所有 Python 源文件语法，编译 build/bin/owner_progress_bench 与 build/bin/flowbench。该目标不加载内核调度器。真实调度器构建使用独立内核工作树：

KERNEL_SRC=/path/to/linux-6.17 ./scripts/build-kernel.sh
export KERNADAPT_SCX_BIN_DIR=/path/to/linux-6.17/tools/sched_ext/build/bin

运行方法

make demo
python3 src/agent/run_kernadapt_online.py --help
python3 src/agent/run_mariadb_comparison.py --help
python3 src/flowcausal/src/controller/flowctl.py --help

make demo 用合成输入演示方案检查、执行权限和状态保存，并核算 openEuler 实验数据。结果写入 results/demo/，演示不调用模型或加载内核调度器。操作步骤见演示说明。

在兼容环境中加载 LockCausal 的方法、退出检查、数据库复现参数和可选在线控制器配置见构建与运行。

测试方法

make test             # 29 个控制平面检查脚本
make test-all         # 再加入 FlowCausal 调度逻辑测试及实验数据核算
make verify-results   # 核算 openEuler 实验记录：140 个样本、28 个工作点

测试记录在 tests/results/。实验环境、协议、失败案例和复现入口见 tests/README.md。

两类专用调度机制

LockCausal：锁交接前后的调度

LockCausal 记录每把锁的等待者、已确认的持锁者和最近运行的 CPU。LockBoost 在解锁前给持锁者有限的额外运行时间，LockNest 在唤醒后依据同一把锁的 CPU 记录选择执行位置。实验分别测量 CPU 放置和时间片扩展的作用。

LockCausal 系统架构

在 256 线程 MariaDB OLTP 实验中，相对 scx_simple，openEuler ARM64 节点 0 吞吐为 5.30 倍、p95 降低 **84.8%**；x86 全机不绑定为 4.14 倍、p95 降低 **82.2%**；RISC-V 为 2.15 倍、p95 降低 **56.6%**。各平台分别与同机同批次基线比较。

在 x86 CPU 干扰实验中，LockCausal 相对仅启用 LockNest 的吞吐增加 **9.6%–36.1%**，批处理完成工作量差异不超过 **0.53%**。ARM64 全机资源域锚定相对首次观测锚点的吞吐为 2.69 倍，轮间 CV 从 18.19% 降至 **4.41%**。实验还覆盖 PostgreSQL、SQLite、RocksDB，检验不同锁路径和共置压力下的适用性。

论文 · 补充附录 · 源码与图表

FlowCausal：工具返回关系与会话公平调度

在线实现由 C 登记程序和 BPF 调度器组成。每个会话使用独立的控制组（cgroup），将同一工作流的进程归为一组；通过进程创建、实际阻塞、唤醒和退出维护工具返回依赖。外层按会话分配 CPU，内层对确认的返回依赖提供短片提前运行，并将服务计入所属会话。实现同时处理本地 futex 唤醒额度、临时权重服务记账和 yield 后重新分派。

FlowCausal 系统架构

在 4 个 CPU、8 个并发工作流的实验中，每种方案交错运行 3 轮。FlowCausal 的平均工作流完成时间由原生 Linux 的 25.986 s 降至 24.084 s，降低 **7.32%**；全部完成时间由 52.201 s 增至 53.584 s，增加 **2.65%**。

独立的跨命令依赖原型在 4 CPU、8 个后台进程的固定工作量消融中，将平均完成时间从 4.828 s 降至 4.065 s，降低 **15.79%**。该机制在上述八工作流回放中未带来额外收益，因此单独列为实验原型。

论文 · 源码与图表 · 逐轮汇总

总体研究路线

KernAdapt 总体研究路线

已知限制

BPF/sched_ext API 与构建依赖随内核版本变化；内核模块使用独立构建入口。
性能结果对应指定内核、CPU/NUMA、数据库版本及缓存与存储协议。
futex 竞争事件不必然提供可靠 owner；证据不足会移除相应优化。
FlowCausal 回放评估 CPU 可见工具工作，范围不包含模型推理与远程 API 等待。
在线模型端点、凭据、完整内核树和第三方数据镜像不随仓库分发。

许可证

根目录 MIT License 适用于相应原创控制平面和文档；带 GPL-2.0 等 SPDX 标识的文件遵循自身许可。依赖及其许可证见第三方依赖与许可证。