📊 本周速览：4 条主线 / 7 篇

论文总数 < 20，按 cs.OS overlay 约定不做逐方向长卡片，这里只给主线归类；全部 7 篇均在下一节做工程师视角深度解读。

• 异构内存与页面放置（1 篇）：Memory Fit — 给 OS 一个"页面与哪类内存最契合"的精确硬件信号，对标 Linux TPP。
• 存储栈重构（2 篇）：eFDP 用 eBPF 在 stock kernel 上自动学习数据生命周期并分配 FDP handle；FS-SSD 把 NFS 语义嵌进 NVMe 命令，让外设绕过 host 直接做文件 I/O。
• 机密计算与隐私（2 篇）：CORDE 在 CVM 内实现"限制或声明"的可问责数据披露；AltoPIR 用 Intel AMX 把 PIR 批处理吞吐拉高一个量级。
• AI 系统与 agent 调度（2 篇）：UMLoad 消除 UMA 平台上模型加载的权重拷贝；ToolSched 把资源模型直接嵌进 MCP shell 接口，为并发 agent 错峰执行命令。

Memory Fit: Architectural Support for Page Placement by Learning Models of Good Behavior

Chun Deng, Hui Sub Shim, Evan Laufer, et al.（共 7 人，末位 Philip Levis）· 2026-11-05 · cs.OS / cs.AR

🎯 核心问题
服务器主存正在变成 zswap + CXL memory expander + PCM 的混合体，OS 必须决定"这一页放哪层"。但可用信号只有三种，全都不理想：access bits 便宜却粒度太粗、out-of-band profiling 拿不到运行时真相、runtime instrumentation 精确但开销高。缺一个既精确又便宜的页面—内存亲和度信号。

🔧 关键方法
提出 memory fit 这一硬件抽象：直接度量某页与系统中每类内存的"契合程度"，并显式把测量机制（mechanism）与 OS 的搬迁策略（policy）解耦——硬件只负责给数，策略仍归内核。配套算法 STM（soft trace matching）的关键洞察是：不必在线跑 profiling，而是把某页的访问序列与一个预先学到的"该类内存的好 trace 模型"做比对，即可估算 fit 值，计算与空间都很省。状态开销做到每 4 KiB 页仅 64 bit，且能在每次主存访问时更新，而不是周期性采样。

📊 实验或论据
真实硬件路径：在 BOOMv3 RISC-V 处理器上实现 memory fit 与 STM，跑 Linux 6.6。extended GUPS 上，memory fit 的放置能恢复"到最优放置性能差距"的 2.2–3.8 倍于 Linux TPP。Redis 场景在 DRAM 与 PCM 等容量下，memory fit 恢复 80% 的差距，TPP 只有 19%（placement replay 方式）。运行时代价：OS 内核通知处理开销仅 1.2%。

⚠️ 局限
这是架构级方案，需要处理器/ISA 支持（BOOMv3 上的实现），现有商用 x86 无法直接启用。"好 trace 模型"如何跨 workload 泛化、模型训练与更新成本，abstract 未提及；Redis 结果是 placement replay 而非在线闭环运行。需读全文确认。

💼 对系统人的启示
做 CXL 内存分层 / tiered memory 的团队值得花 30 分钟：它给出了"精确亲和度信号应该长什么样"的接口草案。即便硬件短期不落地，STM 的思路——用 learned model 比对访问 trace 取代在线 instrumentation——也可以借来改造 TPP 类策略的采样与冷热判定环节。

eBPF-Driven Adaptive Lifetime-Aware Data Placement for Shared FDP SSDs

Hajin Moon, Taewan Noh, Chaeeun Yoon, et al.（共 7 人，末位 Youngjae Kim）· 2026-11-04 · cs.OS

🎯 核心问题
NVMe FDP 靠"把不同生命周期的数据分开写"来减少 GC 拷贝、压低写放大。但共享服务器上多租户产生的 lifetime class 数量远超 SSD 提供的 placement handle 数量。已有做法要么静态映射、要么依赖应用特定知识，抓不住运行时真实生命周期，也无法随 workload 漂移自适应。真正的难点是两问：哪些数据会一起死？在有限 handle 预算下分离哪些类收益最大？

🔧 关键方法
eFDP 是一个纯 eBPF 系统，跑在 stock Linux kernel 上，对未修改的应用透明。它通过跟踪 writes 与 invalidations 来识别 lifetime class，并估算"分离这两个类能省下多少 GC 拷贝"——把放置问题变成一个带预算的收益最大化问题。分配策略是两段式：先保证每个租户各拿一个 handle（隔离底线），再把剩余 handle 按预估收益从大到小分给最值得分离的类组合。活跃租户变化时触发 re-plan，重排布局。

📊 实验或论据
两个平台：emulated FDP SSD 上跑 4 个数据库租户，消除的超额写放大是 tenant-level isolation 的 2 倍，且每个有写入的租户吞吐提升 19–23%。企业级 FDP SSD 上给定 RocksDB 的 level 结构，eFDP 用 3 个 handle 就追平需要 5 个 handle 的手工优化放置。租户切换后 7 分钟内完成 re-plan，一小时后写放大仍比原布局低 25%。

⚠️ 局限
评估集中在数据库类租户（RocksDB / DB workloads），日志型、对象型写入模式的效果未提。re-plan 需要 7 分钟量级，对租户频繁进出的场景可能明显滞后。收益估算依赖 eBPF 能观测到的 write/invalidate 事件，若应用绕过 page cache 直写（O_DIRECT）则观测面变化，abstract 未讨论。

💼 对系统人的启示
这是"用 eBPF 把存储策略自动化"的可落地样板：不改应用、不改内核、不需要应用配合，运维多租户 NVMe 池的团队可以直接抄它的接口设计。最值得借鉴的一点是把 handle 分配建模为"预算约束下按 GC 节省量排序"，而不是拍脑袋的静态映射表。

File-Semantic SSD for I/O-centric Architectures with NFS-over-NVMe Protocol

Kyu-Jin Cho, Injae Kang, Keunsan Park, et al.（共 8 人，末位 Jin-Soo Kim）· 2026-11-04 · cs.OS

🎯 核心问题
I/O-centric 架构让外设（DPU / SmartNIC / 加速器）绕过 host CPU 与内核直接访问存储。但 SSD 只暴露 block 接口，文件元数据与访问控制全在 host 文件系统里——于是外设和远端设备想做 file-level 访问就绕不开 host。host FS 与存储设备的这种紧耦合带来不可避免的软件开销，也堵死了真正 hostless 的 I/O 路径。

🔧 关键方法
FS-SSD 把原生 file 抽象做进 SSD 内部，让外设与远端设备无需 host 介入即可直接访问文件。协议选型上取了个巧：不发明新语义，而是复用轻量、stateless 的 NFS 接口，并提出 NFS-over-NVMe——把 NFS 操作嵌入标准 NVMe 命令结构的协议扩展。这样一来，本地 file I/O 走 PCIe、远端 file I/O 走 NVMe-oF，两套已有传输都不用改。

📊 实验或论据
abstract 只给出定性结论：FS-SSD 在 I/O-centric 架构下提供 on-device file 抽象的同时，能充分利用 raw-device 带宽。具体延迟/吞吐数字、对比 baseline、硬件或仿真平台均未提及——需读全文。

⚠️ 局限
最明显的是 abstract 缺少量化结果，无法判断收益幅度。其次是工程代价：把 NFS 语义下沉到设备，意味着 SSD 控制器要承担元数据管理、访问控制与一致性，固件复杂度与故障域都会扩大。stateless NFS 语义能否覆盖需要强一致、文件锁、原子重命名的应用场景，abstract 未提。

💼 对系统人的启示
对做 computational storage / DPU 的人，这篇的价值主要在路径选择：与其自造一套设备侧文件接口去赌标准化，不如挑一个已经 stateless、语义清楚的既有协议（NFS）塞进 NVMe 命令。即便不动固件，也值得评估"NVMe-oF + 设备内文件语义"能否在你的 I/O 路径上削掉 host FS 这一层。

Enforcing Accountable Disclosure in Confidential AI

Shumpei Shiina, Haruka Takahashi, Kento Sasaki, et al.（共 5 人）· 2026-11-04 · cs.CR（primary）/ cs.OS

🎯 核心问题
CPU/GPU confidential computing 已经能做到"LLM 处理用户 prompt 而服务商与基础设施运营方都看不见"。但现实里 AI agent 必须把 prompt 派生的信息发给外部服务，服务商也需要有限披露来做安全监控和故障诊断。纯"全部封死"的 CVM 模型在真实 agent 工作流下直接不可用——需要一个既保持默认封闭、又允许可控外泄的机制。

🔧 关键方法
提出 Confine or Declare 原则：用户派生数据默认被限制在 CVM 内，只有先被"declare"才允许离开。declare 的定义很具体——把数据的确切内容、接收方、声明理由三者记入一份用户可访问、tamper-evident 的 declaration log。落地上是三件套的组合：Rust 实现的 per-user information-flow control 做强制、TEE-based ledger 做防篡改存证、remote attestation 做可信根。相当于把 IFC 从"拦截"扩展成"拦截 + 可审计放行"。

📊 实验或论据
在 NVIDIA H100 GPU 上评估。关键数字是开销：在 AppWorld agent benchmark 上，"披露前先 declare"给任务延迟带来的额外开销约 0.5%——基本可视为免费。

⚠️ 局限
开销只覆盖任务延迟，attestation 与 ledger 的运维复杂度、日志规模增长、用户实际查阅成本都未量化。机制的根本边界在于：它能保证"声明被如实记录"，但声明理由的语义正确性仍依赖策略与人——技术上可审计，不等于自动合规。评估限于单一 GPU 平台与单一 agent benchmark。

💼 对系统人的启示
对做机密计算或合规 AI 服务的团队，这是一个可直接借用的策略框架：把"数据出境"从网络策略的一刀切，变成带审计痕迹的显式动作，既能满足安全监控需求又能对用户交代。Rust IFC + TEE ledger + attestation 的具体接合方式值得读全文抄设计。

UMLoad: Fast On-Demand Model Loading on Unified Memory Architecture

Zimeng Wang, Jinrong Yang, Rong Chen（共 3 人）· 2026-11-03 · cs.OS / cs.AR

🎯 核心问题
端侧交互式 AI 的响应延迟，主要被 on-demand model loading 吃掉。UMA（统一内存架构）在边缘设备上已经普及，理论上应该让加载变得很便宜——权重本来就放在 GPU 能直接看到的内存里。但 llama.cpp / PyTorch / vLLM 这些框架仍在沿用为 discrete GPU 设计的"分配 + 拷贝"加载流程，白白付了一遍内存带宽。

🔧 关键方法
UMLoad 是系统级加载加速器，核心动作是把框架的 logical allocation 与 physical page backing 解耦。两个具体技术：(1) on-demand reconstruction——按需重建物理页内容，从而消除权重拷贝，同时保留 copy independence（源与目标互不影响这一原有语义）；(2) GPU-assisted page zeroing——把运行时分配的页清零工作交给 GPU 加速，同时保留清零原本提供的安全保证（不让新分配读到残留数据）。两点都是"省掉开销但不牺牲原语义"的做法，这是它能直接替换现有 loader 的关键。

📊 实验或论据
覆盖面很宽：在 Intel、AMD、NVIDIA 三家 UMA 平台实现，用 llama.cpp、PyTorch、vLLM 跑 6 个模型。平均加载时间相比 vanilla 降低 36.6%–71.9%，相比已做流水线优化的 pipelined loader 仍降低 19.9%–62.7%。端到端指标：LLM-routing 的 mean TTFT 降低 51.3%–59.3%，model-backed tool 的完成延迟降低 10.2%–31.6%。

⚠️ 局限
适用面被 UMA 限定——服务器侧 discrete GPU + 独立显存的场景不受益。on-demand reconstruction 要求能拦截框架的分配路径，对自定义 runtime 或加密权重格式的支持 abstract 未提。GPU-assisted page zeroing 的安全边界（谁保证零化真的完成、失败如何回退）需读全文确认。

💼 对系统人的启示
做边缘/端侧推理框架的人可以直接自查：如果你的 loader 在 UMA 设备上还在走 memcpy 老路，这里有 30%–70% 的加载时间可拿，TTFT 收益更明显。更通用的启发是"logical allocation 与 physical backing 解耦"这个手法——任何要 mmap 大文件、又想避免一次性物化的 runtime（不只是模型权重）都能套用。

ToolSched: Resource-Efficient Tool Scheduling for Shared-Host LLM Agents

Shucheng Zou, Yuhao Gu, Long Chen, et al.（共 6 人）· 2026-11-03 · cs.OS

🎯 核心问题
本地 LLM agent 常常跑在共享主机上，而这类主机的内存、CPU、I/O 都紧（不同于资源弹性大的多租户云集群）。多个 agent 并发执行 shell 命令时频繁争抢资源，直接导致 OOM 之类的失败和资源效率低下。现有做法要么靠 cgroup 限流（太粗），要么不管（互相踩）。

🔧 关键方法
出发点是一个很聪明的观察：agent 的资源需求是 bursty 的，而 shell 命令的延迟对 agent 本身不可感知——agent 在等 LLM 推理，不在乎命令晚几秒返回。于是"何时、以何顺序真正执行命令"存在巨大调度空间。ToolSched 做成一个 Shell MCP Server，把资源模型直接嵌进 MCP 接口：agent 提交命令时同时给出资源需求估算；这些 hint 加上实时主机资源状况共同决定实际执行时机。内部用调度算法错峰执行以减少争抢，并配 prediction correction 与 checkpoint-based recovery 来兜住估算偏差和资源错误。

📊 实验或论据
在 Terminal Bench 上评估。相比不调度的直接执行：资源利用率提升 148.4%，端到端命令吞吐提升 29.4%。

⚠️ 局限
整套机制建立在"agent 自愿提供资源 hint"之上——prediction correction 能修偏差，但恶意或系统性错误的 hint 的影响 abstract 未讨论。评估仅 Terminal Bench 一个 benchmark。另外它的前提"命令延迟对 agent 不可感知"在人类交互式 shell 或有时限的工具链场景下不成立，这类场景的可接受性未讨论。

💼 对系统人的启示
这是把经典 OS 调度思想（错峰、准入控制、checkpoint 恢复）搬到 MCP / agent 工具层的具体样本，而且抓准了一个真实的调度自由度。做多 agent 本地运行时的团队最该借鉴的是接口设计：让资源 hint 随工具调用一起上报，比事后从 cgroup 观测再反压更早一步、也更准。

High-Throughput Private Information Retrieval with on-CPU Accelerators

Gyuyeong Kim（单作者）· 2026-11-02 · cs.OS / cs.CR / cs.DB

🎯 核心问题
PIR 靠"扫描整个数据库"来隐藏客户端到底取了哪条记录，batching 是让多条查询共享这一次扫描、从而提吞吐的标准手段。但现有 CPU 方案从 batching 里几乎拿不到好处——每条查询仍要做自己的那批乘法，而 SIMD 向量指令一次只能做几个。转向 GPU 等离散加速器虽然算得快，却要额外硬件，而且显存容量反过来卡死了数据库规模。

🔧 关键方法
AltoPIR 是首个利用 on-CPU matrix accelerator（Intel AMX）的 PIR 系统。设计重点不在算力本身，而在"别让加速器饿着"：数据由 CPU cache 直接喂给 AMX，一批查询中每个数据库字节只从内存读一次供所有查询复用，且中间乘积从不写回内存。这正好把 batching 的理论收益变成实际收益，同时避开了离散加速器的显存墙。

📊 实验或论据
相比现有 CPU-based 方案，吞吐最高提升 50.1×；并且能服务大于 GPU 显存容量的数据库——这两点合起来正是它相对 GPU 路线的差异化优势。abstract 未给出单查询延迟、数据库规模与具体 AMX 平台型号，需读全文。

⚠️ 局限
强绑定 Intel AMX 这类 on-CPU 矩阵扩展，其他 ISA（AMD、ARM）上没有对应路径，可移植性受限。abstract 缺少延迟与规模细节，也没有与 GPU 方案的直接数字对比（只说了容量优势）。单作者工作，工程成熟度与是否开源未提。

💼 对系统人的启示
对隐私计算与数据库团队，这篇更大的启示是AMX 不只服务 AI 推理：任何"以矩阵乘为核心、且同一份数据要被反复扫描"的密码学原语（PIR、同态加密、Oblivious RAM 的某些构造）都可能被它加速，而且不受显存容量约束。cache 供给 + 中间结果不落内存这两条，也是通用的加速器喂数据准则。

团队规模分布（37 位作者 / 7 篇，平均 5.3 人）

条形颜色对应所属主线：绿=存储栈，靛蓝=异构内存，蓝=AI 系统与 agent，红=机密计算与隐私。

署名与分类明细

本周合作结构观察

• 没有跨论文的共同作者：37 位作者全部唯一（Youngjae Kim / Jin-Soo Kim / Gyuyeong Kim 为不同人），本周 cs.OS 内部看不到可观测的合作链，符合该方向"小组独立作战、单周体量小"的常态。
• 典型的"系统大组"署名结构：Memory Fit（7 人）、eFDP（7 人）、FS-SSD（8 人）都是多名学生 + 资深末位作者（Philip Levis / Youngjae Kim / Jin-Soo Kim），这类工作通常伴随完整原型实现。
• 小团队与个人项目同样出彩：UMLoad 仅 3 人却覆盖三家 UMA 平台 + 三个框架；AltoPIR 是本周唯一单作者论文，也是唯一的 cs.OS/cs.CR/cs.DB 三分类交叉工作。
• 与相邻方向高度重叠：7 篇中 4 篇带 cross-list——cs.AR ×2（Memory Fit、UMLoad）、cs.CR ×2（CORDE、AltoPIR）、cs.DB ×1（AltoPIR）。本周 cs.OS 的边界基本压在体系结构与安全两侧。

1. "数据放在哪一层"是本周的统一下层主题（4/7）

Memory Fit 决定页面放哪类内存、eFDP 决定数据放哪个 FDP handle、UMLoad 决定逻辑分配何时物化成物理页、FS-SSD 决定文件语义放设备内还是 host。四篇的共同方法论是：把放置决策从静态启发式变成可测量、可学习的机制，并显式做 mechanism / policy 分离（Memory Fit 说得最直白，ToolSched 则把资源模型直接嵌进接口）。

2. AI 负载开始改写 OS 侧接口，而不只是当 workload（3/7）

CORDE 把 agent 的对外调用当成 CVM 的一等信息流来管；UMLoad 针对"框架为 discrete GPU 设计的加载流程在 UMA 上失效"这一具体错配下手；ToolSched 更进一步——把资源估算塞进 MCP 协议本身，让工具调用携带调度所需信息。三者共同指向一个正在成型的"agent-aware 系统接口层"：调度与隔离的输入不再只来自内核观测，也来自 AI 侧的显式 hint。

3. 隐私从二元开关走向"可问责的中间态"

CORDE 不再假设"数据一律不许出 CVM"，而是给出 Confine-or-Declare：可以出，但内容、接收方、理由必须进 tamper-evident 日志，代价只有约 0.5% 延迟。AltoPIR 则从另一侧解决"查询模式泄露"。两者合起来说明机密计算研究的关注点正从"能不能封住"转向"封不住的部分如何审计与度量"。

4. 专用硬件能力已是标配前提（5/7）——工程师要先看可复现性

本周依赖具体硬件特性的论文占多数：BOOMv3 RISC-V 上的自定义抽象（Memory Fit）、Intel AMX（AltoPIR）、NVIDIA H100 confidential computing（CORDE）、GPU-assisted page zeroing（UMLoad）、FDP SSD（eFDP，含 emulated + 企业级实盘两种）。好处是数字扎实，代价是可移植性。阅读建议：先确认硬件前提是否满足，再决定是否投入 30 分钟读 PDF——其中 eFDP（stock Linux + eBPF）与 UMLoad（三家 UMA 平台）的落地门槛最低。