MARS: Multi-stage Accelerated Read Stack for Large-buffer Buffered Reads

Yang Shen, Kai Lu, Min Xie + et al. · NUDT（推测）· 2026-07-15

🎯 核心问题
数据密集型应用越来越多地使用大缓冲区读取（MiB 级别）来摊销 syscall 开销，但 Linux 的 buffered read 路径只利用了"减少 syscall 次数"这一个好处。在大范围读取内部，内核仍然以细粒度页缓存操作交错执行——反复在 page-cache lookup、fault handling、数据拷贝之间切换——导致元数据开销被放大、无法向现代并行 NVMe SSD 暴露足够的 in-flight I/O。

🔧 关键方法
MARS 将每次大范围读取视为一个完整工作单元，把 page-cache 操作按数据结构和依赖关系分阶段（stage）执行。在 I/O 等待期间，MARS 提前处理用户态缓冲区的 page fault 并完成可重排序的数据拷贝。然后使用投机性内核 worker 线程并行执行剩余的数据拷贝；当后端存储提供足够并行度时，还可选择并行提交 I/O。核心思路是把原先交错的细粒度操作解耦为可以流水线化和并行化的多个阶段。实现在 Linux 6.6.58 上。

📊 实验或论据
在 MiB 级 fio 读取测试中，MARS 相比原版 Linux 带宽提升最高 6.56 倍。在 5 块 NVMe SSD 的 RAID0 配置上，128 MiB 随机读取达到 36.87 GiB/s，是 Linux 的 4.44 倍。实际应用场景下，DuckDB/Parquet 查询加速 1.80–2.15 倍，ExecuTorch 模型加载加速 3.17–3.61 倍。评估覆盖了分析型查询和 ML 模型加载两类实际 workload。

⚠️ 局限
聚焦于同步大缓冲区 buffered read 场景；未提及与 io_uring 异步路径的交互或比较。对小 I/O 或随机小块读取的适用性未讨论。分阶段设计可能增加对页缓存内部锁竞争模式的敏感度。

💼 对系统人的启示
这是一篇非常实战的 Linux 内核 I/O 栈优化工作。如果你的场景涉及 ML 模型加载、大文件分析查询，MARS 的多阶段思路值得关注——36 GiB/s 的读取带宽在纯 buffered I/O 路径上是很惊人的数字。补丁基于 Linux 6.6 LTS，如果能 upstream 将直接惠及生产环境。

Cross-Core Inference Offload as an Operating-System Service on Dual-Core Microcontrollers

Dimitrios Kafetzis · 独立研究者 · 2026-07-14

🎯 核心问题
NXP MCXN947 这类双核 MCU 天然不对称：第二个 Cortex-M33 缺少 FPU、DSP 扩展、TrustZone 和 MPU。如何在这种硬件不对称性下安全高效地让应用核调用推理能力？现有做法通常在应用侧直接链接推理库，无法利用双核优势，也无法做隔离。

🔧 关键方法
SynapticOS Phase 3 将 AI runtime（模型、NPU/DSP、调度器）固定在能力核上，应用核只能通过消息式远程系统调用访问推理服务。传输层是共享 SRAM 中的一对 lock-free 单生产者/单消费者环形缓冲区——每个方向一个 writer、使用 free-running 32-bit 计数器、仅靠数据内存屏障保序（该平台无跨核原子操作）。张量数据在共享 slot 中零拷贝传递——27 KB 的帧在 64 KB RAM 中不能存两份。应用核重启后可无协助地重新加入。MPU region 保护 runtime 核对应用核 RAM 的访问。

📊 实验或论据
在 FRDM-MCXN947（双核 150 MHz）上测量：应用核启动 1,514 µs，握手完成 2,554 µs，11 次启动 bit-identical。跨核往返延迟典型 15 µs / 最差 81 µs（预算 50 µs）。push 操作 25 cycles。1,913 次双模型连续服务零错误。报告了两个硬件缺陷发现：向擦除 flash 释放第二核会卡死整块芯片（现用 ROM-API blank check 防范），以及 Zephyr flash 驱动 Kconfig 静默禁用了 devicetree MPU guard（改为运行时编程）。

⚠️ 局限
保护是单向的——应用核无 MPU，ARMv8-M 无法阻止特权读取。仅在一款 NXP MCU 上验证，其他双核 MCU（如 RP2040、STM32H7）的适用性未讨论。推理延迟来自 stub NPU，非真实硅片吞吐。

💼 对系统人的启示
对于嵌入式系统工程师来说，这是一个很好的"把 AI 推理做成 OS 服务"的参考设计，尤其是 lock-free ring + 零拷贝共享内存的方案在资源受限平台上很优雅。Apache 2.0 开源，代码可直接参考。但要注意 stub NPU 的局限——真实 NPU 延迟加入后系统行为可能不同。

Inference Pipelines as Operating-System Objects: Priority Scheduling and Constant-Footprint Streaming for Microcontroller Neural Inference

Dimitrios Kafetzis · 独立研究者 · 2026-07-14

🎯 核心问题
MCU 上的推理 pipeline（预处理→加速器调用→后处理）被当成应用层代码：每个项目都要重新实现 stage 编排、buffer 分配和完成通知。作者认为这些应该是操作系统的职责。

🔧 关键方法
Phase 2 将推理 pipeline 提升为一等 OS 对象：从静态池分配 pipeline，按规范的 stage 顺序校验，由优先级作业调度器执行（realtime > normal > best-effort，每类内 FIFO）。Stage buffer 根据配置和张量几何精确计算（内置 9 种处理器，用户自定义 stage 有 4x 上界回退）。所有中间数据存活在每帧重置的 ephemeral arena 中——流式内存占用恒定。调度路径无堆分配。

📊 实验或论据
NXP FRDM-MCXN947 上测量：调度器相对 Phase 1 直接 HAL 调用仅增加 92 µs 开销（1,130 vs 1,038 µs；dispatch 本身 1 µs）。6-stage 人脸检测 pipeline 30 帧平均 4.63 ms/帧（215.8 FPS，含 stub 模型）。Arena 峰值恒定 2,784 字节，每帧归零。PowerQuad DSP 路由后 FFT 加速 5.51x、matmul 1.66x——但作者坦承未达 10x 目标，直接标记为"missed, not re-scoped"。99 个测试 100% 通过。

⚠️ 局限
仍使用确定性 stub NPU kernel 而非真实加速器。PowerQuad DSP 加速未达预期目标。9 种内置处理器的通用性有待验证。固定优先级调度对实时混合负载的公平性分析较弱。

💼 对系统人的启示
"inference pipeline 是 OS 对象"这个抽象很有意思——ephemeral arena 保证恒定内存是 MCU 场景的刚需。作者诚实报告 DSP 加速未达标反而增加了可信度。如果你在做 MCU 上的 ML 部署，这套分层架构值得参考。

SynapticOS: An Inference-First Runtime Architecture for Neural Processing Units on Resource-Constrained Microcontrollers

Dimitrios Kafetzis · 独立研究者 · 2026-07-14

🎯 核心问题
带片上 NPU 的 MCU 已成主流，但系统软件没跟上：Zephyr 或 FreeRTOS 搭配 TFLite Micro 把推理当应用层库用，内存碎片化、加速器状态管理、模型生命周期守护全推给应用开发者。

🔧 关键方法
Phase 1 提供四个协作子系统：(1) 张量感知的 bump allocator——16 字节 DMA 对齐、persistent/ephemeral 双生命周期共享单一 arena，常数时间分配（~154 cycles/call），零碎片化（by construction）；(2) NPU/DSP 的 4-state HAL——含确定性软件 stub（CI/QEMU 用）和 Neutron 风格后端（NXP MCXN947 用）；(3) 3-state 模型生命周期注册表——重名检测、幂等 load/unload、热切换保护；(4) 4-mark cycle-accurate profiler。

📊 实验或论据
FRDM-MCXN947 上 67 KB flash / 184 KB SRAM（含 shell 和 128 KB arena）；QEMU 上 24 KB flash / 28 KB SRAM。端到端推理延迟：FRDM 1,038 µs、QEMU 781 µs（16×16×3 INT8 输入，stub kernel）。Allocator 在 150 MHz 下达 ~78,000 allocs/sec，不随张量大小变化。61 个测试 100% 通过，CI 耗时 6.6 秒。

⚠️ 局限
所有推理延迟数据来自确定性 stub kernel，非 Neutron 真实硅片测量（作者明确表示真实 SDK invoke 在 Phase 2 到达）。目前仅在单一 NXP 平台验证。Bump allocator 的零碎片化以不支持任意 free 为代价，适用场景有限。

💼 对系统人的启示
作为 SynapticOS 三部曲的基础层，这篇定义了内存管理和硬件抽象的基本契约。bump allocator + ephemeral arena 的设计非常适合推理这种"帧驱动"的 workload。代码 Apache 2.0 开源，如果你在嵌入式 AI 运行时上做类似工作，Phase 1→2→3 的渐进式架构演化是一个很好的工程案例。

PolyQ: Codesigning End-to-End Quantization Framework for Scalable Edge CPU LLM Inference

Hyunwoo Oh, Suyeon Jang, Hanning Chen + et al. · UC Irvine（Imani Lab）· 2026-07-16

🎯 核心问题
CPU 上部署低比特量化 LLM 时，现有方法要么只提供粗粒度的量化档位（如统一 4-bit），要么提供细粒度混合精度但难以在 CPU 上高效执行。问题在于 per-channel 不同 bit-width 导致的内存布局不规则性，使 SIMD 执行低效。

🔧 关键方法
PolyQ 做编译器/量化协同设计：先按 activation 感知策略为每个 channel 从 {2,3,4,8,16} 中分配 bit-width，满足用户指定的平均比特预算。然后在编译时做 channel 置换和聚簇——把相同 bit-width 的 channel 归到连续块中，生成 SIMD 和 LUT 兼容的 kernel，并在算子间合并兼容的置换以避免运行时重排开销。核心创新是把细粒度比特预算拟合转化为一个"编译时布局正则化"问题。

📊 实验或论据
在 Falcon-H1-3B、Llama2-13B、Qwen3-32B 上用 WikiText-2 评估：3b 目标下困惑度比 prior methods 改善 2.4–32.1%，3–6 bit 范围内质量平稳缩放。在工作站、笔记本、手机三类 CPU 上端到端测量：编译时布局正则化减少最多 70.8% 的 activation 重排流量，prefill 延迟和 decode 吞吐与比特预算近线性关系，能耗开销低于 2%。

⚠️ 局限
bit-width 候选集固定为 {2,3,4,8,16}，未探索其他组合。编译时置换策略对算子图结构有依赖，复杂模型的算子间置换合并是否总能成功不明确。质量评估仅用 WikiText-2 困惑度，未测下游任务准确率。

💼 对系统人的启示
如果你做 CPU 端 LLM 部署，PolyQ 的"编译时搞定内存布局、运行时零开销"思路很有工程价值。70.8% 的重排流量减少说明混合精度的瓶颈不在计算而在数据搬运——这和系统工程师的直觉一致。值得关注后续是否会开源编译器。

ExaGEMM: Exploration Framework for CPU-Driven ML Inference via Associative In-Register Computing for Low-Bit GEMM

Hyunwoo Oh, Suyeon Jang, Hanning Chen + et al. · UC Irvine（Imani Lab）· 2026-07-16

🎯 核心问题
极低比特 GEMM（1/2/4-bit 权重 × 不同精度激活）在常规 CPU 上执行效率很差。不同精度组合在固定 SIMD 宽度和寄存器文件预算下的可行性、复用机会和支持成本各不相同，使得"选择支持哪些精度组合"成为一个设计空间探索问题。

🔧 关键方法
ExaGEMM 是一个 workload-aware 的协同设计与探索框架。核心洞察：现有 SIMD 数据通路已覆盖查表和累加，唯一需要的新硬件是一个 in-register select/feed 机制。框架使用解析模型（寄存器可行性、计算成本、内存流量、硬件开销）在仿真前剪枝 99.2% 的候选空间，然后找到非支配（Pareto）支持点，自动生成 ISA 规范、gem5 补丁和 GEMM kernel 进行验证。

📊 实验或论据
在代表性 ML 模型和 CPU 目标上，ExaGEMM 相比纯软件基线延迟改善 13.29 倍。验证在 gem5 仿真器上完成。论文强调 workload-aware 的 frontier 选择对混合精度 LLM 工作负载特别重要。

⚠️ 局限
仅在 gem5 仿真器上验证，无真实硬件实现。提出的 ISA 扩展尚未在 FPGA 或流片中验证。13.29x 加速基线是纯软件方案，若与已有的 AMX/VNNI 等 ISA 扩展对比可能差距缩小。

💼 对系统人的启示
这是一篇偏 CPU 架构探索的工作，与 PolyQ 是姊妹篇——ExaGEMM 探索"需要什么硬件支持"，PolyQ 探索"如何在现有硬件上编译优化"。对于关注 CPU ISA 演进（如未来 RISC-V 扩展、x86 AVX 后续指令）的系统架构师，框架的解析建模 + Pareto 探索方法论值得借鉴。但短期工程价值有限——等有真实硅片或 FPGA 原型再关注不迟。

值得注意： Dimitrios Kafetzis 以独立作者身份一周内提交了 SynapticOS 三篇 Phase 论文（Phase 1→2→3），涵盖从内存管理到推理 pipeline 再到跨核 offload 的完整 OS 栈设计。这种"一人写完一整个运行时"的工作在 cs.OS 社区并不常见。Imani Lab 的 ExaGEMM 和 PolyQ 则是典型的"硬件探索 + 编译器落地"姊妹篇配对发表模式。

ML 推理正在"下沉"为操作系统的一等公民

本周 6 篇论文中有 5 篇直接围绕"如何在系统层面更好地支持 ML 推理"展开——从 MARS 优化模型加载 I/O，到 SynapticOS 把推理 pipeline 做成 OS 对象，再到 PolyQ/ExaGEMM 的编译器 + ISA 协同设计。这不是巧合，而是一个明确信号：ML 推理不再只是应用层的事，它正在重塑 OS 的内存管理、I/O 栈、调度器和硬件抽象层。

尤其值得关注的是 MCU 端：SynapticOS 三部曲表明，即便在 Cortex-M33 + 64 KB RAM 这种极端资源受限环境下，"推理即 OS 服务"的抽象也是可行且有工程价值的。随着边缘 AI 芯片（带 NPU 的 MCU）的普及，嵌入式 RTOS 的架构可能需要根本性重新设计。

Linux I/O 栈仍有巨大优化空间

MARS 在 buffered read 路径上实现了 6.56x 的带宽提升和 36.87 GiB/s 的吞吐——这些数字说明 Linux 现有的 page-cache 交错路径在面对 NVMe SSD 阵列时已成为严重瓶颈。在 io_uring 主导异步 I/O 叙事的当下，同步 buffered read 的优化容易被忽视，但 ML 模型加载、数据分析等场景的需求真实存在。