网络栈与共享基础设施 (1)

用 eBPF 在共享 datapath 上做"租户可编程 + 强隔离"的尝试。

• Chamelio — 用 bounded eBPF fast path + cycle accounting 同时拿到可编程性和性能隔离

CXL 与内存解耦 (2)

CXL 3.0 内存语义开始进入 OS 层抽象，从单机扩展到集群、从主存扩展到加速器。

• DPC — 把整个集群当一块 page cache，单副本 CXL 远程映射
• Proxics — 给 NDP 加速器一个像 Unix pipe 一样的进程/IPC 抽象

调度与实时性 (2)

从地面无人机到在轨卫星，资源约束下的调度仍是 OS 老问题的新场景。

• Equinox — 用 barrier function 把电池/温度/队列压成单一 marginal cost 信号
• PREEMPT_RT on RPi5 — 实测 Linux RT 在多核 SoC 上的剩余抖动主要来自硬件内存争用

AI Agent 安全与机密计算 (2)

Agent 普及把 OS 安全话题带回前线：本周一篇用 IFC 做 host 端隔离，一篇用 Arm CCA 做 edge 端 TEE。

• GAAP — 信息流控制 + 持久化 store，agent 不可信也能保证数据不外泄
• AgenTEE — 把 agent runtime / 推理引擎拆进多个 Arm CCA cVM，<5.15% 开销

GPU / 加速器运行时 (1)

小算子主导的 LLM 推理让 kernel launch 开销重新成为瓶颈。

• GPUOS — persistent kernel + NVRTC 运行时注入算子，PyTorch 透明集成 15.3x 加速

Chamelio: A Fast Shared Cloud Network Stack for Isolated Tenant-Defined Protocols

Matheus Stolet, Simon Peter, Antoine Kaufmann · 2026-04-24

🎯 核心问题
云网络虚拟化要么走多层 guest/host 栈（CPU 高、tail latency 长），要么用 fixed-function 的共享栈（性能好但租户改不了协议）。eBPF 看起来是答案，但它的 verifier 只保证安全，不保证性能隔离——一个租户的 per-packet 处理可以拖死整片邻居的尾延迟。

🔧 关键方法
Chamelio 把共享栈拆成 bounded eBPF fast path + tenant slow path：fast path 是有"周期预算"合约的 eBPF，运行时做 cycle accounting 把超额工作驱逐到 slow path。第二招是 joint compilation——把租户 handler 和 provider 基础设施、共驻租户一起编译优化。第三招是这个 bounded contract 本身使强隔离与可编程性兼容。

📊 实验或论据
租户实现的可编程 TCP 跑到 9.2 Mreq/s，与手调 TAS 持平；joint compilation 把 programmability tax 从 23.9% 压到 3.8%；在一个 scaling TCP adversary 下，没有保护的栈受害者尾延迟飙到 154 µs，Chamelio 把它压在 46 µs。

⚠️ 局限
abstract 没明说，但 bounded fast-path 的周期预算意味着复杂租户协议会频繁掉到 slow path，slow-path 性能特征值得关注；joint compilation 要求 provider 拿到所有租户代码做共编译，这在多租户实际部署中调度复杂度未提及。

💼 对系统人的启示
eBPF verifier 只解决安全，性能隔离要靠运行时的 cycle accounting——这个思路对自家用 eBPF 做共享 datapath 的团队（Cilium、Katran 类）非常实用。"bounded contract + 超时降级"是个能直接迁移到其他共享子系统（存储、调度）的设计模式。

DPC: A Distributed Page Cache over CXL

Shai Bergman, Zhe Yang, Julien Eudine, et al. · ETH/华为 · 2026-04-21

🎯 核心问题
分布式文件系统在每个节点维护各自的 page cache，热数据在集群里被多份复制——浪费 DRAM、还要靠重量级锁协议维持一致性。能否把整集群 DRAM 当成一个 cache 池？

🔧 关键方法
DPC 在 OS 层基于 CXL 3.0 内存语义实现 page cache，**强制单副本不变量**：每个 file page 只有一个 owner 节点持有 DRAM 拷贝，其他节点通过 CXL remote mapping 读写而不是复制页面。这样从根上消除了多副本一致性协议——硬件 cache coherence 替代了软件锁。

📊 实验或论据
在自建的 multi-host CXL 3.0 fabric 仿真平台上端到端实现并评测，覆盖真实和有代表性的数据共享 workload。最高 12.4× 加速，几何平均 5.6×。

⚠️ 局限
评测全在 CXL emulation 上，真机 fabric 的延迟、抖动、错误处理还没法验证。单副本不变量在写密集场景下，owner 节点会成为热点；abstract 没提 owner 迁移代价。

💼 对系统人的启示
分布式存储工程师值得读：未来 CXL 3.0 fabric 一旦商用，"远程访问 vs 本地复制"的权衡会重做一遍，DPC 给了一个早期参考。即使现在没硬件，单副本 page ownership 这个抽象也可以借鉴到 RDMA-based 分布式 cache 设计。

Proxics: an efficient programming model for far memory accelerators

Zikai Liu, Niels Pressel, Jasmin Schult, et al. · ETH (Roscoe 组) · 2026-04-20

🎯 核心问题
CXL 内存池让 NDP（Near-Data Processing）重新热起来，硬件设计在出，但缺干净、可移植的 OS 抽象——程序员不知道怎么编程，硬件厂商各搞各的接口。

🔧 关键方法
把 NDP 加速器抽象成"虚拟处理器（进程）+ IPC 通道（像 Unix pipe）"。但天真实现行不通：NDP 上算力少，传统 process 太重；shared buffer 形式的 IPC 在"省内存带宽"的系统上违背初衷。Proxics 通过编译期协作 + 利用互联协议本身来实现轻量化进程和无共享 buffer 的通道——具体是把通道映射到互连的消息原语。

📊 实验或论据
在真实硬件平台上跑了 bulk memory ops、in-memory database、graph application 三类访问模式。结果不仅展示对纯 CPU 实现的优势，还**强调** CPU 与 NDP 之间低延迟通道的关键性——这个在已有 NDP 论文里被严重忽视。

⚠️ 局限
abstract 没给具体 speedup 数字，对比 baseline 也没列；编译期协作意味着 NDP 上跑动态语言或运行时生成的代码会受限。

💼 对系统人的启示
内核 / runtime 工程师的实质收获：NDP 不要重新发明编程模型，"进程 + pipe"足够熟悉、足够正确。如果你在做 CXL 内存池或近存计算，先把 host-device 通信延迟当一等问题对待，不要先搞数据布局。

GPUOS: A GPU Operating System Primitive for Transparent Operation Fusion

Yiwei Yang, Xiangyu Gao, Yuan Zhou, et al. · 2026-04-20

🎯 核心问题
LLM 推理、attention、micro-batched 训练里全是小算子，单次 kernel launch 开销有时候超过实际计算时间。CUDA Graphs 类方案需要静态形状，不灵活。

🔧 关键方法
GPUOS 跑一个长生命周期的"worker kernel"，不停从 host 端 atomic 任务队列里取活；用 NVIDIA NVRTC 运行时编译算子，通过 device function pointer table 注入到运行中的 kernel。四个关键设计：(1) persistent worker kernel + atomic task queue，(2) 基于 NVRTC 和可重定位 device code 的算子注入，(3) dual-slot aliasing 让算子并发更新安全，(4) 通过 TorchDispatch 透明地 batch micro-op 成统一提交。支持任意 shape/stride/dtype/broadcasting。

📊 实验或论据
在小算子主导的 workload（micro-batched 推理、attention pattern）上比 stock PyTorch 加速最多 15.3×。保持 PyTorch 生态兼容。

⚠️ 局限
长 kernel 占用 SM 影响 GPU 多租户调度；NVRTC 编译延迟在首次执行新算子时可能很大，abstract 没给冷启动数字；对 AMD/Intel GPU 的可移植性不明。

💼 对系统人的启示
推理引擎和 ML 框架工程师应当读：这个"GPU 操作系统"思路（任务队列 + 长驻 worker + 动态注入）可以作为 vLLM/TensorRT 之外的另一条优化路径，尤其适合形状高度动态的 agent / 多模态推理场景。

GAAP: An AI Agent Execution Environment to Safeguard User Data

Robert Stanley, Avi Verma, Lillian Tsai, et al. · 2026-04-21

🎯 核心问题
AI agent 要做"通用个人助理"必须能访问私人数据，但 prompt injection 可以让 agent 把数据外泄给攻击者，或不可信的模型 provider 偷偷收走。基于"信任 model + 信任 prompt"的方案根本不成立。

🔧 关键方法
GAAP 是一个 agent 执行环境，**把 agent 当不可信模块对待**：通过动态、定向的用户 prompt 收集 permission spec（描述哪些私人数据可以分享给谁），然后用 Information Flow Control + 持久化 data store + annotation 同时跟踪：(a) 单个任务里多步执行间的数据流，(b) 跨任务的长期数据流。强制 agent 对 model 与 provider 的所有 disclosure 都符合 spec——确定性保证，不依赖 model 或 prompt 的安全性。

📊 实验或论据
评测显示 GAAP 阻止了所有数据 disclosure 攻击，包括能让其他 SOTA 系统外泄数据的攻击；同时 agent 实用性没有显著下降。具体 baseline 和数字 abstract 未列出。

⚠️ 局限
"permission spec via dynamic prompts" 的 UX 是个未知数——如果用户被频繁打断回答 "可以把 X 发给 Y 吗"，实用性会快速塌方；跨任务跟踪需要持久化 store，存储和审计开销 abstract 未提。

💼 对系统人的启示
做 agent runtime 的团队（OpenAI Apps SDK、Claude Agent SDK 等）值得参考：IFC 是上世纪老技术，但放到 agent 这个新场景下解决了"模型不可信"的根本问题。比 sandbox 类方案语义清晰、可证明。

AgenTEE: Confidential LLM Agent Execution on Edge Devices

Sina Abdollahi, Mohammad M Maheri, Javad Forough, et al. · 2026-04-20

🎯 核心问题
LLM agent 越来越多放到边缘设备跑（降延迟、保隐私），但要保护 system prompt、模型权重、运行时状态等敏感资产，而边缘设备本身可能被恶意用户控制，且平台异构。

🔧 关键方法
AgenTEE 把 agent runtime、推理引擎、第三方 app 分别放进**独立 attest** 的 confidential VM (cVM)，组件间只通过显式可验证的通信通道交互。底层用 Arm CCA（Confidential Compute Architecture，Armv9 新扩展），强制系统级隔离敏感资产和 runtime state。多 cVM 设计避免了把整个 agent pipeline 塞进一个 enclave 的复杂度。

📊 实验或论据
实测显示多 cVM 系统是实用的，对比 commodity OS 的多进程部署，运行时开销 <5.15%，接近原生性能。

⚠️ 局限
Arm CCA 真机普及率仍低（Realm Management Extension 当前仅在最新 Armv9-A 平台），对边缘市场（手机、IoT）实用性受限；abstract 没给 attestation 的延迟和启动开销，模型权重加载到 cVM 的内存占用也未提。

💼 对系统人的启示
做端侧 AI（手机厂商、edge inference 框架）的团队应跟进。"per-component cVM + 显式通道"是个比单一大 enclave 更可维护的架构，能直接迁移到 Intel TDX、AMD SEV-SNP。Arm CCA 落地后，这套方法可能成为安卓端侧 AI 的默认部署形态。

Equinox: Decentralized Scheduling for Hardware-Aware Orbital Intelligence

Ansel Kaplan Erol, Divya Mahajan · 2026-04-21

🎯 核心问题
地球观测卫星正在变成时间敏感任务的分布式边缘平台，但在轨调度有难题：能源是断续收割的（光照才发电）、有时间耦合（现在猛干会让未来电池耗尽）。现有调度器靠静态优先级，没法自适应丢任务。

🔧 关键方法
Equinox 把电池电量、热余量、队列积压等时变约束用一个 barrier function 压缩成单个 state-dependent **marginal cost of execution**——接近安全极限时陡升，同时编码当前压力和未来风险。本地任务只在"价值 > 当前 cost"时执行，自然实现 value-ordered load shedding；如果本地 cost 比邻居高，任务通过卫星间链路动态卸载——分布式负载均衡，不需要路由协议或全局状态。

📊 实验或论据
143 卫星星座的多日仿真，物理模型基于 Jetson Orin Nano 实测。比基于优先级调度，科学 goodput +20%、图像处理吞吐 +31%，电池均值储备高 2.2×；高负载下，比静态调度执行率高 5.2×。

⚠️ 局限
评测是仿真不是真上轨；barrier function 的参数调优看起来需要离线工作，新型号卫星部署时调参成本未提。

💼 对系统人的启示
"把多个时变约束压缩成单一 marginal cost"这个思路对地面分布式系统也有价值——比如多租户云调度里把 CPU/内存/电力/温度合成一个 admission cost。barrier function 是控制论老工具，OS 调度领域用得不多，可以借鉴。

Scheduling Analysis of UAV Flight Control Workloads using Raspberry Pi 5 Using PREEMPT_RT Linux

Luiz Giacomossi, Håkan Forsberg, Ivan Tomasic, et al. · 2026-04-21

🎯 核心问题
现代 UAV 想把高层自主和底层飞控统一到一个 GPOS 上跑，但多核 SoC 的共享资源争用带来时序不确定性。PREEMPT_RT 究竟够不够？哪些抖动还在？

🔧 关键方法
在 Raspberry Pi 5 上做 PREEMPT_RT 内核分析，重点对比两条 kernel activation path：deferred 执行的 SoftIRQ vs 实时 direct activation，应用是 250 Hz 控制循环。隔离测量 OS 噪声 vs 硬件噪声两个来源。

📊 实验或论据
重压力下 stock kernel 完全不可用，最坏延迟 >9 ms。PREEMPT_RT 把最坏延迟降到 <225 µs（约 88% 削减），靠的是 direct wake-up path 绕过 OS 噪声。但**残余 jitter 主要来自硬件内存争用**，不是调度器。

⚠️ 局限
单一平台（RPi5），结论不一定推广到其他 Arm SoC；250 Hz 是中等控制频率，更高频实时任务（kHz 级电机控制）未测。

💼 对系统人的启示
实时性工程师和机器人 / 工业控制工程师都要读：明确告诉你 PREEMPT_RT 能解决一半问题，另一半要靠**硬件层手段**（cache partitioning、MPAM、core isolation）。新人容易以为开 RT kernel 就够了，这篇是清醒剂。

本周 8 篇，机构呈现明显的"老牌系统强组 + 跨学科合作"格局：

值得注意：本周没有出现"同一组多篇刷榜"的情况，8 篇 8 个独立组——cs.OS 周更通常如此，社区小但不卷。

1. AI agent 是 OS 安全今年的主战场

8 篇里有 2 篇专门做 agent 隔离（GAAP 走 host-side IFC、AgenTEE 走 edge-side TEE），方法分别代表"软件信息流"和"硬件机密计算"两条路线。这两条路明年大概率会汇合——把 IFC 跑在 cVM 里。做 agent 平台的工程师现在就要开始想"模型/prompt 都不可信"的威胁模型，sandbox 不够。

2. CXL 3.0 终于开始进入 OS 抽象层

DPC 和 Proxics 都在 CXL 3.0 内存语义之上重写 OS 抽象——前者重做 page cache，后者重做进程/IPC。这是 CXL 从"硬件标准存在"走向"OS 重构"的拐点。然而两者都靠 emulation 评测，真机生态还有 1-2 年。提前阅读这些论文，准备好自家系统的 CXL-aware 改造路线图。

3. "Persistent kernel"成为 GPU runtime 通用模式

GPUOS 用长驻 worker kernel + 任务队列的设计与近年 vLLM、Mirage、Hidet 等工作思路相通——这背后是 LLM 推理 small-op 化驱动的根本性转变。CUDA Graphs 静态约束太强，"GPU 上的微内核"看起来要赢。