SchedBlame: Who Ran While You Waited? Culprit-Attributed CPU Contention for Containers on Stock Kernels

Hao Li, Tonghao Zhang, Honglei Wang · 机构未明示 · 2026-09-02

🎯 核心问题
容器共享物理机 CPU 时产生争抢，现有指标（PSI、per-cgroup wait counters、run-queue latency histogram）全部是受害者视角——只告诉你"你等了多久"，不告诉你"谁占着 CPU 导致你等"。要定位罪魁祸首，要么改内核、要么全量 scheduler tracing（开销太大不能常开）、要么统计推断（多受害者共存时不可靠）。生产运维里这是一个长期悬而未决的归因黑洞。

🔧 关键方法
SchedBlame 是一个纯 eBPF tracer，在 stock kernel 上运行，不需任何内核 patch。它反转了记账方向：不测受害者等了多久，而是测"受害者 runnable 但没上 CPU 期间，每个其它 cgroup 消耗了多少 CPU 时间"。实现上在 4 个 scheduler hook 维护一个 per-CPU bitmap，标记哪些被测 cgroup 正在等待。每个 run slice 携带该 bitmap，一条 16 字节记录就能给 competitor × victim 的 blame matrix 整行充值，内核不存任何 per-pair 状态。测量集的重配通过 epoch 发布实现，常数时间内废止所有缓存和 per-CPU bitmap。采样模式下用逆保持概率缩放，估计器无偏。

📊 实验或论据
在未修改的 Linux 4.18 和 5.10 内核上生产部署，监控 96 核主机上的 84 个容器。Redis 吞吐开销约 1%，CPU 开销约 6% 单核。能把每个容器的秒级 CPU 需求拆分为 runtime / internal contention / external contention / throttling 四部分，并基于滚动 99 分位基线标记异常、点名竞争者。

⚠️ 局限
bitmap 宽度限制了同时可测的 cgroup 数量（abstract 未明确上限）。仅覆盖 CPU 维度争抢，内存带宽 / LLC 争抢等 noisy-neighbor 问题不在范围内。4.18 内核年代久远，更新内核的 scheduler 路径（如 EEVDF）是否影响 hook 点需验证。

💼 对系统人的启示
这是一个可以直接部署到生产环境、不改内核就能回答"谁害了我"的工具。对于运营大规模容器混部集群的团队，这个归因能力填补了现有可观测性栈里最关键的空白——有了 blame matrix，调度策略和 QoS 隔离就有了闭环数据。强烈建议关注是否有开源实现。

NACRE: Rethinking Confidential Containers through Native Architectural Support

Linke Song, Wenhao Wang, Weijie Liu, Rui Hou · 机构未明示 · 2026-09-03

🎯 核心问题
Linux 容器共享宿主内核以获得高密度和快速生命周期，但被入侵的宿主可以窥探或修改容器状态。现有机密计算方案要么保护 enclave 地址空间，要么保护整个 guest OS，近期的容器粒度方案仍然添加独立的保护上下文。没有人把"宿主管理的一组动态 Linux 进程"直接作为架构级保护单元。

🔧 关键方法
NACRE 是一个 RISC-V 硬件-软件协同设计。核心洞见是分离宿主的资源管理权限和访问/提交受保护状态的权限。硬件识别的容器身份将受保护 trap 路由到隔离的 S-mode agent，而 M-mode monitor 负责提交安全敏感的身份、映射和页面状态转换。Agent 将服务委派给宿主 Linux，但不切换 satp；既不访问私有字节也不修改受保护状态的服务还能跳过 M-mode。原型扩展了 QEMU、OpenSBI、Linux、可信 agent 和 runc，实现了单容器私有内存基底，覆盖了 launch / fault / fork+COW / user-access / teardown 路径。

📊 实验或论据
基于 QEMU 的 RISC-V 原型。五个 lmbench syscall/pipe 指标的三次平均值在 runc-origin baseline 的 3.5% 以内。八个 nginx 对象大小的加权聚合吞吐量仅低 1.9%。数字很好看，但是在 QEMU 模拟器上的，不是真实 RISC-V 硬件。

⚠️ 局限
原型仅在 QEMU 上完成，距离真实 RISC-V 硬件还有距离——QEMU 上的性能数字无法反映真实 TLB/cache 开销。当前只实现了单容器的私有内存基底，多容器间的隔离和容器编排（如 Kubernetes pod 级别）场景未覆盖。对 RISC-V 生态的依赖意味着短期内无法在 x86/ARM 主流生产环境部署。

💼 对系统人的启示
这篇的核心 insight ——"管理权 ≠ 访问权"——在概念层面非常有启发性，对于思考下一代 confidential computing 架构很有价值。但工程落地需要等 RISC-V 硬件生态成熟，或者类似思路被移植到 x86/ARM 的 TEE 扩展中。适合做概念参考，短期不可直接采用。

mzCache: On-Device LLM Memory Management under Multitasking

Hongseung Yu, Minsung Kim, Jongseok Park, Kyunghan Lee · 机构未明示 · 2026-09-01

🎯 核心问题
移动设备上跑 LLM 推理时，用户频繁切换 App 会产生内存压力，OS 会驱逐 LLM 的 model weights 和 KV cache。下次推理请求到来时要么从慢存储重新读取，要么重算整个 KV cache，响应延迟严重恶化。这是端侧 LLM 落地的核心体验瓶颈之一。

🔧 关键方法
mzCache 利用移动 SoC 的统一内存架构实现"零等待"推理：在 GPU 上用可用部分的权重启动推理的同时，CPU 端并发恢复被驱逐的内存。关键设计包括：(1) LLM 内存被切分为细粒度的 shared buffer，支持部分驱逐和部分恢复，且允许跨处理器并发访问；(2) hybrid swap 策略结合 backward-out 驱逐策略，确保从任何驱逐状态都能低延迟恢复。整体思路是"恢复导向的内存管理"。

📊 实验或论据
基于 llama.cpp 实现，部署为 Android 应用。与 storage-backed partial offload 对比，Time-to-First-Token 降低 2.1–5.5×。在真实多任务切换场景中验证了效果。具体的模型规模、设备型号、Android 版本 abstract 未详述。

⚠️ 局限
强依赖移动 SoC 的统一内存架构（CPU/GPU 共享物理内存），在离散 GPU 的桌面/服务器场景不适用。abstract 未提及对不同 SoC（高通 vs 联发科 vs 苹果）的兼容性。驱逐/恢复粒度的最优配置可能因模型架构而异。

💼 对系统人的启示
端侧 LLM 推理的内存管理正在变成一个严肃的系统问题，不再只是"把模型塞进去就行"。mzCache 提出的"恢复导向"思路和利用统一内存做 CPU-GPU 并发恢复的模式，对做移动 AI 系统的团队很有参考价值。基于 llama.cpp 实现，工程化门槛不高。

Adaptive KV Retention for LLM Agents at Human-Approval Timescales

Minseo Choi, Ananya Joshi · 机构未明示 · 2026-08-31

🎯 核心问题
Agentic LLM 请求不同于普通 LLM serving——它们可能因等待人类审批而被挂起数分钟甚至数小时，远超先前 agent-serving 系统针对的秒级 tool-call 暂停。核心矛盾非常尖锐：保留挂起请求的 KV state 可以快速恢复，但会吃掉 GPU 容量导致活跃请求 goodput 下降 41%；驱逐它则避免了驻留开销，但恢复延迟高达近 10×。

🔧 关键方法
提出分层保留控制器（tiered retention controller），核心概念是 GPU opportunity cost——用统一的 GPU 时间成本来衡量保留或重建一个挂起请求 KV state 的代价。在主机内存层，控制器根据校准等待样本在"无限保留"和"负载索引过期"之间选择，不需要对每个请求做等待时间预测。设计避开了预测难题，用统计策略代替逐请求建模。

📊 实验或论据
在人类审批尺度的工作负载上评估。相比 vLLM baseline，活跃请求 goodput 提升 23–51%；相比 MORI 提升 22–29%；相比 Continuum 提升 41–52%。Baseline 选择覆盖了当前主流 LLM serving 系统。具体的模型规模和 GPU 型号 abstract 未提及。

⚠️ 局限
"人类审批等待"的工作负载分布假设在真实生产中可能差异很大——不同业务的审批延迟分布完全不同。控制器依赖校准样本，冷启动阶段的表现不确定。仅考虑了 KV retention 这一维度，未涉及 LoRA adapter 或模型权重的混合调度。

💼 对系统人的启示
随着 LLM agent 进入真实业务流程（需要人类审批的操作），serving 系统面对的不再是毫秒级请求而是分钟/小时级挂起。这篇工作把 "GPU opportunity cost" 显式化的思路值得 serving 框架（vLLM、TGI 等）借鉴，尤其是在 agent 场景变多的当下。

Influence of Logging Frameworks on Bind9

Max Schrötter, Hannes Signer, Bettina Schnor · 机构未明示 · 2026-09-01

🎯 核心问题
基于主机的入侵防御系统（IPS，如 Fail2Ban）依赖应用日志检测和阻断恶意行为。但在高速网络下，日志子系统本身成为瓶颈——攻击者只需产生足够流量淹没日志管道，就能让关键痕迹被丢弃。作者证明，仅需不到 65 Mbps 的 DNS 流量就能击败 Fail2Ban + BIND9 的组合。即使把 iptables 换成 eBPF、regex 换成 Hyperscan，日志后端仍然是瓶颈。

🔧 关键方法
提出 FIPS，一个绕过内核的高性能日志 IPC。使用 per-thread 无锁共享内存 ring buffer，支持多个独立消费者以各自速度读取同一日志流，将日志消息的拷贝降到最低。提供原生 API 和 syslog 接口的 drop-in 替换。核心思路是把日志路径从内核 I/O 栈中搬出来，用 shared memory 直连生产者和消费者。

📊 实验或论据
以 BIND 9 为评估对象。FIPS 相比禁用日志几乎没有额外开销；比所有其它日志框架记录了更多请求；使 IPS 封禁恶意客户端的速度比文件日志快 2.5×，在 2¹⁶ 个攻击客户端、每秒百万请求的压力下仍然稳定。

⚠️ 局限
评估仅针对 BIND 9 这一个应用场景。Shared memory ring buffer 意味着生产者和消费者必须在同一台机器上，不适用于分布式日志采集（如需转发到远程 SIEM）。多消费者场景下的内存占用随消费者数量和 ring buffer 大小线性增长，abstract 未讨论上限。

💼 对系统人的启示
"攻击者通过淹没日志来逃避检测"是一个被低估的攻击面。FIPS 的 syslog drop-in 替换特性意味着部署成本低。对于运行高吞吐网络服务且依赖日志做安全防御的场景（DNS、API 网关等），值得关注。技术本身不新（shared memory ring buffer），但工程整合做得扎实。

The Irreversibility Budget: Fleet-Level Risk Accounting and Admission Control for Agent Operating Systems

Bardia Mohammadi, Laurent Bindschaedler · 机构未明示 · 2026-08-31

🎯 核心问题
LLM agent 集群会产生不可完全撤销的副作用——转账、部署代码、删除数据、泄露信息。当前控制机制逐个检查每个动作，所以一群各自获得授权的 agent 可以在同一触发条件下集体超支委托人的风险上限，而每个局部审核都是正确的。这是一个典型的"局部正确、全局失控"的系统性问题。

🔧 关键方法
提出不可逆性预算（irreversibility budget）：由可信运行时为每个 principal 跨 agent、workflow、tenant 维护一个累计残余风险值（residual value-at-risk）。将"不可逆性"作为一等资源（first-class resource），运行时对每个副作用收取其残余损失，一旦累计值将超出预算就拒绝边际操作。核心挑战在于副作用异构、可能被对抗性声明、且存在关联性，"定价"是核心开放问题。

📊 实验或论据
进行了受控实验（controlled study），结果显示：per-effect 审核门允许集群级超支高达租户风险限额的 48 倍，而 irreversibility budget 在正确计费的情况下将每次运行控制在限额内。但这是受控实验而非生产部署，且承认"保守的、依赖感知的定价"仍是核心开放问题。

⚠️ 局限
这是一项概念验证和问题定义工作，距离可部署设计还远。副作用的"价格"如何确定——尤其是面对异构操作和关联风险——是一个基本未解的难题。受控实验环境与真实 agent 部署差距大。没有讨论与现有 agent 框架（如 LangChain、AutoGen）的集成路径。

💼 对系统人的启示
这篇论文的价值不在于给出解决方案，而在于定义了一个正确的问题：agent 集群的不可逆副作用需要全局预算管控，局部审核不够。对于正在构建 agent 编排平台的团队，"irreversibility as a first-class resource" 的思路值得提前纳入架构考虑。但实际工程化需要等定价机制成熟。

观察：本周 6 篇论文来自 6 个独立团队，无跨论文的作者重叠。值得注意的是，有 3 篇（50%）直接涉及 LLM/Agent 的系统层支撑（mzCache、Adaptive KV Retention、Irreversibility Budget），反映出"AI 基础设施系统化"正在成为 OS 社区的新投稿热点。

LLM/Agent 正在重新定义 OS 层的"资源"概念

本周 6 篇论文中有 3 篇（mzCache、Adaptive KV Retention、Irreversibility Budget）直接围绕 LLM 或 Agent 的系统层支撑展开。这不是偶然——

• mzCache 把 KV cache 和 model weights 当作需要弹性管理的内存资源，引入恢复导向的驱逐策略
• Adaptive KV Retention 把 KV state 的 GPU 驻留当作有机会成本的稀缺资源，用经济学思路做分层管理
• Irreversibility Budget 更进一步，把"不可逆副作用"本身定义为需要全局计量的一等资源

传统 OS 管理 CPU、内存、I/O 三大资源。LLM 时代正在催生新的资源维度：KV state 驻留、GPU 时间片的"机会成本"、以及 agent 副作用的"不可逆性额度"。这些概念正在从应用层下沉到系统层，预计未来一年会看到更多此类工作。

eBPF 持续扩展边界：从可观测到归因

SchedBlame 展示了 eBPF 在 stock kernel 上做因果归因（不只是观测）的能力——从"你等了多久"到"谁害你等的"。这延续了 eBPF 从网络过滤→可观测性→主动调度干预的演化路径。随着 eBPF 在 scheduler（sched_ext）和存储路径上的进一步开放，"不改内核就能做深度系统分析"的工具箱将持续壮大。