WIO: Upload-Enabled Computational Storage on CXL SSDs

Yiwei Yang, Yanpeng Hu, Yusheng Zheng, et al. · UC Santa Cruz 系 · 2026-04-02

🎯 核心问题
持久内存与计算式存储（CSD）都想缩小 CPU-存储延迟差，但都没替代 NVMe SSD。原因是编程模型割裂、生态分散，更现实的是 CSD 在持续负载下会撞热墙/功耗墙——一旦掉档就比传统 SSD 还慢。WIO 想问：为什么 storage-side compute 必须是"all-in 在设备里"？

🔧 关键方法
提出 "reversible storage compute"：I/O-path 逻辑被切成 storage actors，编译为 WebAssembly 模块。Actor 间通过 CXL.mem 共享一致性内存区域通信，调度器在感知到热/功耗压力时用 zero-copy "drain-and-switch" 协议把 actor 在 host 与 device 间双向迁移。和此前 SmartSSD/Computational SSD 的差别是：以前是单向 offload（要么烧在卡里要么不烧），WIO 把 offload 视作运行时动态决策。

📊 实验或论据
评估平台是 FPGA 实现的 CXL SSD 原型 + 两块商用 CSD。声称把硬热墙变成弹性 trade-off，吞吐最多提升 2×、写延迟降低 3.75×，且应用零修改。具体 workload 与 baseline 在 abstract 未给。

⚠️ 局限
Wasm runtime 在设备端的内存 / 启动开销 abstract 未交代；FPGA 原型不等于量产 SSD 控制器实测；多 actor 状态一致性在 CXL.mem 之外（如固件升级、断电）的语义需读全文确认。

💼 对系统人的启示
如果你在做 CXL pool / 智能网卡 offload，"reversible offload + Wasm 作为可迁移单元"是一个很值得借鉴的抽象——它把 compute placement 从架构决定变成调度决定。

DAXFS: A Lock-Free Shared Filesystem for CXL Disaggregated Memory

Cong Wang, Yiwei Yang, Yusheng Zheng · 2026-04-02

🎯 核心问题
CXL 让多 host 共享 byte-addressable 一致性内存已经成为现实，但目前没有任何文件系统真正利用这一点做无锁多 host 协调——大多数共享存储 FS 仍依赖中心化 metadata 服务或分布式锁。

🔧 关键方法
DaxFS 把 cmpxchg（CXL 保证跨 host 一致）作为唯一同步原语：CAS-based hash overlay 实现多 host 并发写而无需 coordinator；共享 page cache 用新颖的 MH-clock（multi-host clock）淘汰算法，victim 选择完全去中心化、也只用 cmpxchg。和 Linux DAX / tmpfs 的区别在于不靠任何 lock，纯靠硬件一致性原子。

📊 实验或论据
多 host 正确性用 QEMU 模拟 CXL 3.0 + TCP 转发原子操作，跨 host 竞争下 CAS 准确率 >99% 且无 lost update。单 host DRAM-backed DAX 上：4 线程随机写 2.68× tmpfs，64KB 随机读 1.18× tmpfs。GPU 微基准显示 cmpxchg 设计可扩展到 GPU 线程在 PCIe 5.0 带宽上限做 page cache 操作。

⚠️ 局限
多 host 验证仍然走的是 QEMU + TCP 转发原子（不是真硬件一致性），跨真机的 latency / failure 模式没覆盖。CAS contention 在 host 数变多后是否退化也未给出曲线。

💼 对系统人的启示
如果你在设计 CXL pool 上的 metadata service：DaxFS 给出了一个"无 coordinator"的工程下限——能不能完全只靠 cmpxchg 做出来？答案是肯定的，但要重写算法（CAS hash + clock 改造）。MH-clock 本身可以单独借鉴。

HACache: Leveraging Read Performance with Cache in a Heterogeneous Array

Jialin Liu, Liang Shi, Dingcui Yu · 2026-04-02

🎯 核心问题
现实部署里 RAID 经常是异构：老 SSD 退化但还能用、坏盘换上更新更快的盘。传统 striping 平均分发请求，让最慢的盘成为瓶颈，最快的盘吃不饱。这是一个被工程界长期容忍但很少被正式建模的问题。

🔧 关键方法
把高性能 SSD 当 read cache 来重平衡请求分布。首先把"请求分流"问题形式化并求解；其次提出两阶段分流比动态调整机制，在线搜索最优 ratio；最后用基于命中率与分流需求的 cache 容量调节，给每个 backend SSD 分配 quota。和普通 tiered cache 的区别是：cache 大小不是固定的，是按"消除瓶颈所需的分流量"反推。

📊 实验或论据
针对 read-intensive workload。典型混合配置下带宽提升约 35%。具体 SSD 型号、对比基线（mdraid / bcache / open-cas?）abstract 未列。

⚠️ 局限
只针对 read-intensive，写密集场景未覆盖；分流模型假设性能差异静态可知，但 SSD 老化是连续过程；35% 的提升是在"典型混合"下，最坏/最好情况 spread 未给。

💼 对系统人的启示
运维异构 storage pool（SSD 混代、SSD+HDD）时一个直接可借鉴的思路：cache 不只是热数据加速，更是慢盘流量旁路阀。dm-cache / bcache 用户值得关注它的开源情况。

SteelDB: Diagnosing Kernel-Space Bottlenecks in Cloud OLTP Databases

Mitsumasa Kondo · 2026-03-30 · primary cs.DB（含 cs.OS）

🎯 核心问题
Aurora / Spanner 这类云 OLTP 用极复杂的存算分离 + 共识来追求性能，但同样的硬件在 on-prem 单机本地盘上跑得飞快。作者提出："是不是大家把网络/存储架构当作瓶颈，但真实瓶颈其实在内核 I/O 路径？"——一个挑战行业共识的诊断式立论。

🔧 关键方法
对依赖 OS-level I/O 控制的数据库在云存储下的行为做病理学分析，定位瓶颈位置；据此提炼治疗原则，做成 SteelDB——一个 zero-patch 架构，仅靠 I/O 路径策略（具体机制 abstract 未细说，可能涉及 io_uring / direct I/O / readahead 调参）在通用云分布式块存储上提速，无需改内核也无需改数据库。

📊 实验或论据
TPC-C：最高 9× 性能提升，零额外成本；对标 Amazon Aurora，性能 3.1× 同时成本降 58%，cost-efficiency 7.3×。还有一个有意思的运维数据：Aurora 主版本升级平均 254 天（要把闭源补丁套到新 OSS 版本），SteelDB 零 patch 架构把这部分维护成本降到接近零。

⚠️ 局限
abstract 没说 SteelDB 具体做了什么——只反复强调 "zero-patch / strategic I/O optimization"，工程细节缺失需读全文。TPC-C 9× 是一个非常激进的数字，需看其 baseline 配置（默认 Aurora vs 调优 PostgreSQL+本地 NVMe）。单作者投稿，复现风险偏高。

💼 对系统人的启示
给 DBA / 云架构师一个反向思路：在搬出 Aurora / Spanner 之前，先 perf/blktrace/bpftrace 量一下 kernel I/O 路径——很多"网络瓶颈"其实是 page cache、io scheduler、或者 fsync 行为。值得关注其后续是否开源。

Generative Profiling for Soft Real-Time Systems and its Applications to Resource Allocation

Georgiy A. Bondar, Abigail Eisenklam, Yifan Cai, et al. · UPenn / 多机构 · 2026-04-01 · primary eess.SY（含 cs.OS）

🎯 核心问题
传统 WCET（worst-case execution time）分析无法刻画任务在不同资源上下文（cache 配额、内存带宽、CPU 频率）下的细粒度时序行为，导致软实时系统资源分配只能粗暴留余量。问题是：要不要为每一种 (cache, BW, freq) 组合都跑一遍 profile？组合爆炸。

🔧 关键方法
生成式 profiling：用非参数化、conditional multi-marginal Schrödinger Bridge (MSB) 公式，从已测过的若干上下文出发，合成没测过的资源配置下的执行时间分布，并带最大似然保证。和回归 / GP 拟合的差别是 MSB 直接学 distribution-to-distribution 的传输映射，而非点估计。

📊 实验或论据
在真实 benchmark 上验证；案例研究是多核自适应资源分配。abstract 未给具体 benchmark 名（可能是 MiBench / TACLeBench 之类）和分布拟合误差数字。

⚠️ 局限
Schrödinger Bridge 对训练样本数与上下文维度敏感；soft real-time 不等于 hard real-time，安全关键场景的可用性未论证；在线 profile + 在线推断的开销 abstract 未提。

💼 对系统人的启示
cgroup v2 / Intel RDT / ARM MPAM 的运维者可以关注：与其用 worst-case 留资源 buffer，不如用生成式模型预测 P95 延迟分布，然后做 SLO-aware 的 resource partitioning。这是 ML for Systems 在 OS 调度的一个具体落点。

本周看点：CXL 系统圈的"小团体输出"

Yiwei Yang 与 Yusheng Zheng 同时出现在 WIO 与 DaxFS 两篇里——一篇做 CXL SSD 的可迁移计算，一篇做 CXL 共享内存上的无锁文件系统，是这周最活跃的二人组合，在 CXL 软件栈上左右互搏。WIO 的合作者 Andi Quinn 来自 UC Santa Cruz 系，组里 CXL/storage 工作量明显在加码。

CXL 从硬件议题正式过渡到软件栈议题

本周 5 篇里有 2 篇（WIO、DaxFS）核心立论都建立在"CXL.mem 跨 host 一致性"这个硬件能力上，分别落到计算迁移与无锁文件系统两个截然不同的软件方向。这意味着 CXL 已经从"会不会量产"的争论阶段进入"应该怎么用它来重写 OS 抽象"的设计阶段——cmpxchg 作为唯一同步原语、Wasm 作为可迁移 actor，都是过去在传统 NVMe 时代不成立的设计点。系统工程师值得开始读 CXL 3.0 spec 了。

"零 patch / 应用零修改"成为新卖点

WIO 强调"无需应用修改"，SteelDB 强调"无需 kernel/数据库 patch"。这背后是一种对当前云软件栈复杂度的反弹——研究者意识到任何要求 upstream 内核合并、或要求应用重写的方案都会卡在生态门槛上。下游可移植性正在成为 OS 论文的隐性评价指标。