Facebook 在其数据中心部署了 Steam Deck 的 Linux 调度器——Valve 的低延迟调度器非常适合管理 Meta 在大型数据中心的工作负载

该调度器最初是为了防止 Valve 的 Steam Deck 上掉帧而开发的

当Meta为其庞大的服务器群寻找更好的Linux处理器调度器时，它并非从数据中心开始。相反，它最初是从一台掌上游戏电脑开始的。在最近于东京举办的Linux管道工大会上的一场技术演讲中，Meta工程师详细介绍了他们如何将SCX-LAVD——一款最初由Valve为Steam Deck开发的低延迟Linux调度器——部署在运行从消息后端到缓存服务的生产服务器上。令人惊讶的结论是：一个设计用来保持游戏在负载下响应的调度器，也非常适合大规模数据中心工作负载。

从高层次来说，CPU 调度器决定哪些程序可以在哪些 CPU 核心上运行，以及何时运行。Linux的默认调度器必须在手机、笔记本、台式机、服务器等任何地方工作——这使得它极为保守。Meta的挑战不同：它运行着拥有数百个CPU核心的庞大机器，工作负载极其多样化，最重要的是严格的延迟目标。在那种环境下，“到处都够好”往往不够好。Meta 希望为每个服务都打造定制调度器，而是更接近全舰队默认的“一刀切”调度器，能够自动适应而无需手动配置。这就是SCX-LAVD发挥作用的地方。

SCX-LAVD 基于 sched_ext 构建，这是一个相对较新的 Linux 框架，使得替代调度器能够在不需重大内核修改的情况下插入内核。简单来说，sched_ext让企业能够安全且渐进地尝试不同的调度策略，而无需分支Linux或维护庞大的补丁集。

LAVD本身代表Latency-Aware虚拟截止时间，如果你留心，这个名字就透露了游戏的秘密。调度器不再依赖静态优先级或手动提示，而是持续观察任务的行为、睡眠、唤醒和阻塞的频率，然后估算哪些任务对延迟敏感。这些任务会提前获得“虚拟截止日期”，提高它们在系统繁忙时及时完成的可能性。

这种做法最初是出于游戏的启发。在Steam Deck上，错过排程截止时间会导致帧数掉落、卡顿或输入响应迟缓。事实上，在数据中心，同样的故障模式表现为网络请求缓慢、消息延迟或服务级目标未达。完全不同的应用，但根本上是同一个根本问题。

在演讲中，Meta的工程师们描述了在将LAVD扩展到服务器级硬件时出现的几个挑战。在拥有数十个核心共享单一调度队列的机器上，争用成为瓶颈。钉顶任务，即只能在某一特定核心上运行的线程，造成了不必要的干扰。网络密集型服务花了大量时间处理中断，以至于调度者的公平性会计失效。

这些问题迫使LAVD对任务队列、时间片和CPU计费的处理方式进行了调整。在多个情况下，Meta 添加了逻辑以更好地保持缓存本地性，或补偿被网络中断淹没的核心，实际上将其视为“较慢”的 CPU。关键是，这些修复不需要按服务配置或手动优先标记。这就是LAVD对Meta的核心吸引力：它根据观察到的行为进行调整，而非硬编码规则。

工程师们还回应了一个显而易见的问题：为Meta服务器优化调度器是否会损害其最初的游戏用途？他们表示，到目前为止，这些变化对Steam Deck来说要么是中立的，要么是有益的，不适用的功能可以用内核标志直接禁用。不过，他们承认实验仍在进行中。

随着Linux成为从掌机到超大规模服务器的通用基础，生态系统某一角落的创新正逐渐渗透到其他角落。在这种情况下，同样的调度逻辑能让一台400美元的游戏电脑感觉流畅，也可能帮助数十亿条消息按时发送。这完美展示了开源软件的力量，也是一个有力的论证，说明“涨潮会让所有船只都高涨”。