前言：“既要、又要、还要”
系统设计中“选择与妥协”是惯用模式。想让系统快如闪电？那可能就得牺牲一点稳定性。追求极致可靠性？对不起，性能请打个折扣。想要快速从崩溃中恢复？那你可能得接受丢失一部分最新状态的风险。想要仿真精确？那改一行代码可能还得重复跑几个小时。性能与可靠构成了“鱼与熊掌不可兼得”的局面。
然而，顶尖高手从不满足于在既定规则里做选择题，他们选择重新定义规则。今年的SOSP'25，就有这么一个Session，来自全球顶尖高校和企业的五篇惊艳论文宣告：OSers不做选择，我们全都要！
-
当系统因资源过载而濒临崩溃，能否在不“错杀”大量无辜请求的前提下，精准“狙击”罪魁祸首，既保住性能又维持高可用？（Atropos） -
当CPU在硬件层面“无声背叛”，产生静默数据损坏（SDC），能否在几乎不增加性能开销的情况下，实时揪出“内鬼”，既要速度又要数据正确性？（Orthrus） -
当软件不幸崩溃，能否既实现亚秒级的“浴火重生”，又确保恢复后的状态万无一失，既要快速恢复又要状态正确？（PHOENIX） -
当面临百万变量、千万约束的超大规模集群资源分配，能否既求得近乎完美的“最优解”，又在分钟级甚至秒级完成决策，既要分配质量又要实时响应？（COpter） -
当设计全新的软硬件协同系统，能否既获得与真实硬件误差极小的精确模拟，又将仿真时间从数小时压缩至数秒，既要仿真精度又要开发效率？（NEX+DSim）
这五项工作，各自攻克了一个看似无解的“两难”困境。它们不仅展示了卓越的工程技艺，更蕴含着颠覆传统思维的深刻洞见。我们一起看看OSers是如何打破常规，实现这些“既要、又要、还要”的艰巨目标的！
Paper 17：Atropos —— 过载风暴下的“外科手术式”救援
论文标题：Mitigating Application Resource Overload with Targeted Task Cancellation
核心思想：当系统被少数请求拖垮时，别再门口搞“无差别”限流了，深入内部，直接“取消”那个最占资源的元凶！
核心困境
系统资源（如数据库的缓冲池、锁）被少数“坏请求”或后台任务霸占，导致大量正常请求超时、失败。传统的入口限流或准入控制，只会错杀大量无辜的“受害者”，而真正的“元凶”还在系统内继续作恶。我们能否在不影响整体吞吐的情况下，精准地消除内部瓶颈？
创新突破
Atropos 的核心洞见是：将过载控制从“入口决策”转变为“运行时决策”。它不再问“这个请求该不该放进来？”，而是问“系统里正在运行的任务中，取消哪一个能最大程度地缓解当前资源瓶颈？”。为此，Atropos 建立了一个面向未来的“收益评估”模型，它会持续追踪每个进行中的任务，并动态计算：
- 资源争用有多严重？（Contention Level）
- 现在取消这个任务，未来能释放多少被争用的资源？（Resource Gain）
基于这个评估，Atropos 就能像外科医生一样，在众多任务中精准定位并移除那个“病灶”（即取消收益最高的任务），从而用最小的代价换取最大的系统健康度提升。
实现亮点
- 应用内嵌探针：通过轻量级API，Atropos在应用内部（如MySQL）对每个任务进行资源归因追踪，实时收集CPU、内存、锁等使用情况。
- 面向未来的收益估算：它不只看任务当前占了多少资源，而是通过任务进度模型，预测其“剩余工作量”所需的资源，避免错误地取消一个即将完成的高价值任务。
- 统一的策略引擎：综合考虑资源争用度、取消收益、任务优先级和SLO目标，做出保留、降级或取消的最终决策，并调用应用内建的安全取消接口执行。
效果与代价
- 效果：在MySQL、PostgreSQL等多个真实应用场景中，Atropos 能在维持 96% 基线吞吐的同时，将 p99延迟控制在正常水平的1.16倍以内，而请求丢弃率平均低于 0.01%。相比之下，对比方案 Protego 的丢弃率高达25%。
- 代价：集成需要一定的开发成本，开发者需要帮助系统识别和标注应用内的关键资源，并确保任务的取消逻辑是安全、一致的。
论文标题：Orthrus: Efficient and Timely Detection of Silent User Data Corruption in the Cloud with Resource-Adaptive Computation Validation
核心思想：给系统做体检太贵，Orthrus开创了“非对称”安全检查：关键数据路径“精查”（重算），其他控制路径“粗查”（校验和），用4%的开销抓住90%以上的内鬼。
核心困境
CPU硬件可能因老化等原因悄悄出错，导致静默数据损坏（Silent Data Corruption, SDC），这对云服务是致命的。传统的解决方案，如在线双机热备（RBV），需要100%的额外资源（CPU、内存）来复制和验证每一次计算，成本高到无法在生产环境中大规模部署。我们能否用极低的代价，及时发现这些“内鬼”？
颠覆性思路
Orthrus的洞见是：放弃“对称”的完全复制，采用“非对称”的混合验证。它观察到，云应用中绝大多数复杂且易出错的计算都发生在“数据路径”上，而“控制路径”（如请求分发、I/O调度）逻辑相对简单。因此，Orthrus提出：
- 数据路径，重点照顾：对处理用户数据的核心计算，在另一个CPU核心上进行异步的、完整的重算和比对。
- 控制路径，轻量扫描：对流经控制路径的数据，只计算轻量的校验和（Checksum），确保其在传输中没被篡改即可。
通过这种“区别对待”的策略，Orthrus将验证资源集中在最关键、风险最高的地方，从而用极小的成本实现了极高的安全收益。
实现亮点
- 核心工作流：主线程在 CPU-A 上正常执行计算，并记录下计算的“快照”（输入、版本化内存等）；一个空闲的 CPU-B 上的验证线程会异步地取走这个快照，独立重算并比对结果。
- 版本化内存：通过特殊指针 OrthrusPtr 管理用户数据，每次修改都会生成新版本。这使得验证过程可以与主流程完全解耦，实现乱序、低同步的验证。
- 资源自适应采样：Orthrus并不验证每一次计算。它会监控系统负载，只在CPU有空闲资源时才启动验证，并优先选择那些包含浮点/向量等更易出错指令的任务，实现成本与覆盖率的动态平衡。
效果与代价
- 效果：平均时间开销仅 ~4%，内存开销 ~25%，远低于RBV的“翻倍”代价。SDC的检测延迟在微秒级，比RBV低2-3个数量级。仅用1个专用验证核心，即可检测约 87%的SDC（4核心增至96%）。
- 代价：它是一种“尽力而为”的检测，而非100%的保证，因为采样可能漏掉某些错误。它也无法检测控制流本身的逻辑错误（比如 if 条件判断错了）。此外，需要开发者对代码进行少量注解来区分数据与控制路径。
Paper 19：PHOENIX —— 浴火重生之术：如何在秒级恢复和状态正确间找到黄金路径？
论文标题：Optimistic Recovery for High-Availability Software via Partial Process State Preservation
核心思想：系统崩溃后重启太慢？PHOENIX给你“乐观恢复”—— 保留大概率正确的核心内存数据重底座，抛弃通常引发bug的线程“瞬态”（如线程栈、临时变量），实现秒级执行逻辑重置，既快又稳。
核心困境
当软件崩溃后，我们面临两难选择：要么完全重启，干净但慢，因为需要从磁盘重新加载所有状态，预热时间可能长达数十分钟；要么从内存快照恢复，快但有风险，因为可能把导致崩溃的“有毒”状态一起恢复回来。有没有办法兼得重启的“干净”与快照的“快速”？
关键思路
PHOENIX的核心洞见是：进程状态并非铁板一块，应区别对待。它观察到，大多数软件 Bug 由“瞬态”状态（如线程栈、临时变量）触发，而系统中最宝贵、最庞大、且大概率未被破坏的是那些“长期”状态（如全局缓存、核心数据结构）。因此，PHOENIX提出：
- 丢弃轻瞬态：彻底抛弃所有线程的执行状态（栈、寄存器）。
- 保留重底座：通过内核支持，将开发者标记的“长期”内存数据（如整个堆或特定数据段）以零拷贝的方式，直接重映射到新进程的地址空间。
新进程从 main 函数干净地重启执行逻辑，但它操作的数据底座却是从旧进程“继承”来的。这就实现了“逻辑重置、数据复用”的完美结合。
实现亮点
- 核心工作流：应用崩溃后，Restart Handler 被触发 -> 调用 phx_restart 指定要保留的内存页 -> 内核执行 preserve_exec，将这些页的页表项(PTE)从旧进程“搬”到新进程 -> 新进程从头开始执行，但可以直接访问那些被保留的旧数据。
- 不安全区（Unsafe Region）：为防止保留被改了一半的“脏”数据，开发者可以标记正在修改核心数据的代码为“不安全区”。若崩溃发生在此区域内，PHOENIX会自动放弃快速恢复，回退到传统的慢速重启，确保数据一致性。
- 交叉验证（Cross-Check）：为了极致的正确性，PHOENIX可以在快速恢复主服务的同时，在后台默默地进行一次完整的慢速恢复。一旦后台恢复完成，它会对比两个版本的数据状态，如果不一致，则无缝切换到后台验证过的“绝对正确”的版本上。
效果与代价
- 效果：将原本需要数十分钟的恢复和预热时间，缩短至亚秒级。在8400次故障注入测试中，成功恢复率高达 85.6%。运行时开销平均仅 2.7%。
- 代价：正确性依赖于开发者对“不安全区”的准确标注。在交叉验证完成前，存在一个短暂的“投机执行”窗口，可能会对外提供基于未经完全验证的数据的服务。
Paper 20：COpter —— 从“独立快照”到“持续优化”，在大规模资源分配中同时追求速度与质量
论文标题：COpter: Efficient Large-Scale Resource-Allocation via Continual Optimization
核心思想：还在把每次调度都当成“新会话”？COpter认为它们只是多轮中的“一轮”，通过复用上次的“上下文”，将求解速度提升了1-2个数量级。
核心困境
在拥有数百万变量的超大规模集群（如GPU集群、广域网）中，资源调度是一个极其复杂的优化问题。商用求解器（Solver）虽然能给出高质量的解，但往往需要数小时，完全跟不上系统秒级到分钟级的变化频率。我们能否在不牺牲分配质量的前提下，将求解时间缩短到实用水平？
关键思路
COpter的洞见是：停止将每一轮调度视为孤立的、全新的问题。在真实系统中，相邻两次调度的变化通常很小（比如只增加/减少了几个任务）。COpter将此过程视为一个“持续优化”的序列，其核心思想是：
- 增量更新：每次只计算系统变化的“增量”部分，而不是从零开始构建整个数学模型。
- 热启动求解：将上一轮的“最优解”作为这一轮求解的“初始猜测值”。由于变化很小，从一个非常接近最优的起点开始，求解器能极快地收敛到新的最优解。
这就像一个经验丰富的学生，他不会每次都从头推导公式，而是会利用已有的知识和结论，快速解决新的、类似的问题。
实现亮点
- 核心工作流：系统状态变化 --> 差分更新接口只修改约束矩阵的增量部分 -->
免因子分解求解器以 上一轮的解作为热启动点，快速迭代求解 -->轻量级整数化启发式地修复少量非整数解 --> 输出高质量调度方案。 - 免因子分解求解器：采用计算成本更低的一阶优化算法（PPA），避免了传统求解器中最耗时的矩阵分解步骤，特别适合在热启动场景下快速收敛。
- 轻量级整数化：在很多场景下，优化问题的解大部分已经是整数了。COpter用一个极快的启发式算法，快速“修正”剩下那一小部分非整数解，绕过了传统方法中耗时巨大的“分支定界”过程。
效果与代价
- 效果：在GPU集群调度、负载均衡等多个真实场景中，求解时间比商用求解器快57-83倍，而分配质量损失几乎可以忽略不计。
- 代价：其核心优势建立在“系统缓慢演化”的假设之上。如果系统状态在短时间内发生剧变，其“持续优化”的收益会下降。对于整数解，它提供的是高质量的近似最优解，而非数学上的绝对最优保证。
Paper 21：NEX+DSim —— 模拟未来：在“真实复刻”与“秒级反馈”之间，真的无法两全其美吗？
论文标题：Fast End-to-End Performance Simulation of Accelerated Hardware–Software Stacks
核心思想：仿真又慢又准，怎么办？NEX+DSim说：软件原生跑，硬件“最小化”模拟，只精算性能关键点，把几小时的等待变成几秒的反馈。
核心困境
在设计全新的软硬件协同系统（如自定义AI加速器）时，全栈仿真是验证性能的黄金标准。但它极其缓慢，模拟1秒钟的真实执行可能要花上数小时甚至数天，这种“史前时代”的开发效率让快速迭代成为空谈。我们能否在保持工程可用精度的同时，获得近乎实时的仿真反馈？
关键思路
NEX+DSim的原则是“最小化模拟”：凡是可以真实运行的步骤就不要去模拟。
- 软件原生执行：操作系统、库和应用程序等软件栈，直接在开发者的主机CPU上以接近原生的速度运行。
- 只模拟“不存在的”硬件：只有当软件需要与那个“尚在设计中的”加速器交互时（如读写寄存器、DMA），才暂停原生执行，切换到仿真模式。
- 性能与功能分离：对加速器的模拟也采用“双轨制”。一条轨道用一个极快的数学模型（延迟皮特里网）来精确预测性能和时序；另一条轨道用一个简单的功能模型来确保逻辑结果正确。二者松耦合，避免了对每一个门电路进行“龟速的”精确模拟。
这种方法将宝贵的计算资源聚焦于“未知”和“性能关键”的部分，从而实现了速度与精度的平衡。
实现亮点
- 核心工作流：软件在主机上原生执行 --> 遇到与加速器的交互指令（如MMIO）触发陷入 --> NEX运行时暂停软件，并把虚拟时钟推进到当前时刻 --> DSim加速器模拟器“快进”到该时刻，处理交互并返回结果 --> 软件解除暂停，继续原生执行。
- 懒惰同步（Lazy Synchronization）：系统以微秒级的“纪元（epoch）”为单位推进。在同一个纪元内，软件和硬件仿真可以各自独立运行，只在纪元结束或发生交互时才进行一次同步，大大减少了同步开销。
- 交互式设计探索：得益于极快的速度，开发者可以像调节音量一样，实时修改硬件参数（如总线延迟、缓存大小），并在几秒内看到对整个应用端到端性能的影响，实现真正的“所见即所得”设计。
效果与代价
- 效果：比传统的gem5+RTL全栈仿真快6到879倍，将数小时的仿真任务压缩至秒级或分钟级。与FPGA真实硬件的实测性能相比，端到端延迟的平均误差在6%-14%之间，完全满足工程设计初期的精度要求。
- 代价：它牺牲了微架构层面的细节可观测性，你无法得到门级信号的精确踪迹。其精度虽然足够高，但无法替代最终流片前最严格的周期级全栈仿真验证。此外，当前模型未完全计入CPU与加速器争用内存控制器的开销。
结语：打破权衡，重塑可能
回顾这五篇杰出的论文，我们不难发现一个贯穿始终的共同主题：打破传统的设计权衡，通过深入系统内部，利用更细粒度的信息和更精巧的机制，来开辟一条兼顾多方目标的创新路径。
- Atropos 将过载控制的焦点从外部的“准入”转向了内部的“运行时”，实现了从“粗放管理”到“精准调控”的飞跃。
- Orthrus 放弃了昂贵的“完全复制”，通过解构应用的“控制流”与“数据流”，实现了“非对称”的、高性价比的在线验证。
- PHOENIX 拒绝了恢复时“要么全丢，要么全留”的简单选择，通过识别状态的“瞬态”与“稳态”属性，创造了“保留稳定大底座”的第三条路。
- COpter 摒弃了将调度视为“孤立事件”的旧观念，通过挖掘问题演化的“连续性”，将昂贵的求解过程摊销到了整个时间序列中。
- NEX+DSim 则挑战了“仿真必须全面精细”的传统认知，通过“最小化”原则，区分了“已有”与“未知”、“性能关键”与“功能正确”，实现了效率与精度的完美平衡。
这些工作表明在系统设计的世界里，许多所谓的“不可能三角”并非牢不可破的物理定律，而是在特定技术和认知水平下的工程约束。OSers 用他们的智慧打破陈规。面对难题，不要轻易妥协，多问一句“为什么不能两者兼得？”，或许就能找到通往未来的钥匙。真正的创新，始于对“不可能”的挑战。OSers不轻易妥协，他们创造新的可能。