Seekable OCI: Lazy-Loading Container Images via Range-Request Indexing

James Thompson, Wayne Mesard, Jesse Butler, et al. · Amazon (AWS) · 2026-07-07

🎯 核心问题
Kubernetes 环境中 Pod 冷启动时间的大头在容器镜像拉取。标准流程必须下载完整镜像才能启动容器，但实际应用启动时只会访问镜像内容的一小部分。对于 GB 级镜像，这意味着 20 秒以上的等待——在 serverless / scale-to-zero 场景中不可接受。已有的 lazy-loading 方案（如 Stargz、Nydus）需要转换镜像格式，增加了运维复杂度和生态兼容代价。

🔧 关键方法
SOCI（Seekable OCI）在标准 OCI 镜像之上构建一个外部索引，将文件映射到压缩层内的字节范围。运行时通过 FUSE 文件系统拦截文件访问，按需发起 HTTP Range Request 获取所需数据。关键设计决策：索引以 OCI Referrer Artifact 形式存储，不修改镜像本身、不要求 registry 做任何改动，也不需要改部署工具链。这与 Stargz 等需要重新打包镜像的方案形成鲜明对比。对于 GPU 实例等需要完整镜像的场景，还提供了 parallel full-pull 模式。

📊 实验或论据
在 1.3 GB Python Web 服务镜像上，冷启动拉取时间从 20 秒降至约 2.8 秒（7.4× 加速）；2.5 GB 镜像上达到 9.3× 加速，因为 SOCI 拉取时间与镜像大小无关，而标准拉取线性增长。论文测出 crossover 点在 80% 访问密度——低于此值 lazy-loading 更快，高于此值并行全量拉取更优。生产验证极为充分：SOCI 自 2023 年起在 Amazon EKS 和 ECS Fargate 上线，Prime Day 2025 当天 Fargate 处理了 1840 万个 task/天。EKS Auto Mode 在 GPU 实例上使用 SOCI 的 parallel pull 模式。

⚠️ 局限
当容器启动时访问镜像内容超过 80% 时，lazy-loading 反而更慢（大量小粒度 Range Request 的 RTT 累积）。FUSE 引入了用户态-内核态切换开销，对 I/O 密集型启动路径可能有尾延迟影响。此外，依赖 registry 支持 HTTP Range Request（主流 registry 均支持，但私有部署需确认）。

💼 对系统人的启示
这不是学术原型——这是经过 3 年生产验证、日均千万级调用的工业系统。如果你在运维大规模 K8s 集群且受冷启动困扰，SOCI 是目前最低侵入性的方案：不改镜像、不改 registry、不改 CI/CD，只加一个索引。EKS 用户可以直接开启。

Complets: Universal Compartmentalisation and Programming Model For Arm Permission Overlay Extension 2

Vasily A. Sartakov · 机构未明示 · 2026-07-06

🎯 核心问题
ARM POE（Permission Overlay Extension）是一种基于内存保护键（memory protection keys）的进程内隔离机制，类似 x86 的 MPK。POE1 相对简单，但 POE2 大幅扩展了能力：引入了新的寄存器和表来管理不同保护键关联代码的操作权限，并增加了"时间索引"这一线程上下文属性。代价是架构复杂度显著上升——有效权限由多个硬件组件交互决定，直接编程极易出错。目前缺乏一个通用的编程抽象来驯服这个复杂度。

🔧 关键方法
论文提出 "Complets" 编程模型，对 POE2 的空间索引（保护键 ↔ 代码/数据区域）和时间索引（线程上下文中的时序属性）进行抽象。在 POE2 中，权限由四个维度联合决定：执行代码的空间索引、被访问内存的空间索引、操作类型、线程的时间索引。Complets 模型将这些映射为高层 compartment 概念，隐藏底层寄存器和表的直接操作。论文给出了安全模型（security model），确保 compartment 之间的隔离保证在 POE2 语义下成立。

📊 实验或论据
📄 Abstract 未提及量化评估或具体实现平台。论文侧重于对 POE2 架构的详细分析和编程模型的形式化定义，属于系统设计与安全模型论证类工作。需读全文确认是否包含原型实现或性能数据。

⚠️ 局限
POE2 是 ARM 架构的前沿扩展，目前实际支持 POE2 的硬件尚未广泛可用（POE1 在 ARMv8.9-A 引入，POE2 更新）。Abstract 未展示实现或实测数据，论文更偏向架构分析和编程模型设计。单作者论文，缺乏工程团队背书。

💼 对系统人的启示
如果你关注 ARM 平台的进程内隔离（例如为 WebAssembly runtime、浏览器沙箱、或 TEE 之外的轻量级隔离寻找硬件支撑），这篇论文是理解 POE2 能力边界和编程复杂度的好入口。实操价值取决于硬件可用性——当 POE2 芯片量产时，这类编程模型会成为刚需。可类比 x86 MPK 早期的学术探索到 Linux pkey(2) 系统调用的演进路径。

Elastic Gang: Per-Token Membership Change for a Hard-Barriered LLM Inference Gang Co-Scheduled with OS Processes

Daeyeon Son · 机构未明示 · 2026-07-06

🎯 核心问题
端侧 LLM 推理的 decode 阶段是 hard-barrier 的 CPU-SIMD 计算：每个 token 需要所有参与核同步执行几毫秒。传统抢占式调度器无法安全处理这种 barrier 同步——如果一个核被抢占，barrier 死锁；如果一个核未经协调加入，logits 被静默破坏。但 OS 的其他进程也需要这些核。核心矛盾：gang scheduling 要求刚性的核集合，而通用 OS 需要弹性的核分配。静态分区会浪费核（推理空闲时核被 strand），动态抢占会破坏正确性。

🔧 关键方法
作者构建了 Anima OS——一个 bare-metal x86-64 Rust 内核，将推理 gang 作为一等可调度实体，核成员关系可在任意两个 token 之间变化。核心机制是 "ACK-latched epoch protocol"：一种 seqlock 风格的 generation-tagged latch 与 RCU/epoch 风格的成员同意机制的组合。每个 token 的参与集 = gang 请求的核 ∩ 当前 epoch 已 ACK 的核。未 ACK 的核不参与当前 token，最迟在下一个 token 加入。被置换的通用进程迁移到其他核继续运行；当一个 generation 结束时核立即返回给通用进程。关键不变式：运行中的 tenant 永远不会被 mid-slice 抢占。

📊 实验或论据
实测平台：AMD Zen 5（8C/16T）。测试了 135M 和 7B 参数模型，验证在 per-token 成员变更下推理输出 bit-exact。与静态 8 核均分对比，弹性调度 Pareto 占优：在 25% 推理 duty cycle 下通用吞吐提升 1.75×，50% 下 1.52×，75% 下 1.28×，且推理吞吐不降。归还一个借出的核延迟 0.22 μs（p50）；获取一个有 tenant 占用的核需等一个调度量子（~16 ms，因为不 mid-slice 抢占）。Decode 吞吐在 gang width = 8 时饱和，超出拐点后让出核几乎零代价。

⚠️ 局限
Anima OS 是一个 bare-metal 研究内核，不是 Linux 模块或补丁——这意味着整个技术栈需要重写才能在生产环境使用。仅在 AMD Zen 5 单一硬件平台上验证，且测试模型最大 7B（端侧主流但不覆盖更大模型的内存压力场景）。获取被占用核的 16 ms 延迟在对延迟敏感的交互推理场景中可能可感知。单作者工作，工程化路径不明确。

💼 对系统人的启示
这篇的核心贡献不是 Anima OS 本身，而是 ACK-latched epoch protocol 这个调度原语——它优雅地解决了"barrier 同步的 gang 如何与抢占式调度共存"的问题。对于正在做端侧推理调度的团队（无论是 Linux scheduler class 扩展还是用户态 runtime），这个 epoch + seqlock + RCU 的组合思路值得借鉴。用 Rust 写 bare-metal 内核本身也是一个有趣的工程实践参考。

本周 3 篇中 2 篇为单作者论文，反映 cs.OS 领域"个人深钻"传统仍然活跃。SOCI 是唯一的工业界团队论文，且有大规模生产背书。三篇论文之间无作者交集。

LLM 正在重塑 OS 研究议题。 本周 3 篇中有 2 篇直接或间接与 LLM 工作负载相关：SOCI 解决的容器冷启动问题在 GPU 推理服务 scale-to-zero 场景中尤为关键（论文明确提到 EKS Auto Mode 的 GPU 实例使用 SOCI）；Elastic Gang 则为端侧 LLM 推理设计了全新的调度原语。LLM 推理的独特特征——barrier 同步、高内存带宽需求、burst 式计算——正在迫使内核和调度器层面产生新的抽象，这个趋势在未来几个季度预计会持续加强。

ARM 安全扩展持续演进。 POE2 对 POE1 的大幅扩展（增加时间索引维度）表明 ARM 在进程内隔离方向上的投入在加深。编程模型的复杂度提升催生了 Complets 这类抽象层的需求——这与 x86 MPK 从硬件特性到 Linux pkey(2) 系统调用再到 PKRU-safe 库的演进路径如出一辙。