当Meta为其庞大的服务器群寻找更好的Linux CPU调度器时，起点并非数据中心，而是一台掌上游戏电脑。在最近于东京举行的Linux Plumbers' Conference技术研讨会上，Meta的工程师详细介绍了他们如何将SCX-LAVD（一种最初由Valve为Steam Deck开发的低延迟Linux调度器）部署到生产服务器上，这些服务器运行着从消息后端到缓存服务的各类工作负载。一个令人惊讶的结论是：这款为保障游戏在高负载下响应灵敏而设计的调度器，同样非常适合大规模数据中心的工作负载。
简单来说，CPU调度器决定哪些程序在何时、在哪个CPU核心上运行。Linux的默认调度器必须适用于所有场景——手机、笔记本电脑、台式机、服务器——这使其变得极其保守。Meta面临的挑战则不同：它运行着拥有数百个CPU核心的庞大机器，工作负载千差万别，最关键的是，有着严格的延迟目标。在这种环境下，“处处够用”往往意味着“处处不够用”。与其为每项服务构建定制调度器，Meta更希望找到一种更接近全舰队默认的、“一体适用”的调度器，能够自动适应，无需手动调优配置。这正是SCX-LAVD的用武之地。
SCX-LAVD基于sched_ext构建，这是一个相对较新的Linux框架，允许替代调度器接入内核，而无需对内核进行重大修改。简而言之，sched_ext让公司能够安全且渐进地试验不同的调度策略，而无需分叉Linux或维护庞大的补丁集。
让LAVD适应Meta的服务器并非易事。LAVD本身代表“延迟感知虚拟截止时间”，其名称揭示了其工作原理。该调度器不依赖静态优先级或手动提示，而是持续观察任务的行为、休眠、唤醒和阻塞的频率，进而估算哪些任务对延迟敏感。这些任务会获得更早的“虚拟截止时间”，从而增加它们在系统繁忙时及时运行的机会。
这种方法最初是为了游戏而设计的。在Steam Deck上，错过的调度截止时间会导致掉帧、卡顿或输入响应迟钝。而在数据中心，同样的故障模式则表现为网络请求缓慢、消息延迟或服务等级目标未达成。应用场景完全不同，但根本上，是相同的底层问题。
在演讲中，Meta的工程师描述了将LAVD扩展到服务器级硬件时出现的几个挑战。在拥有数十个核心共享单一调度队列的机器上，争用成为了瓶颈。固定任务（即只能在一个特定核心上运行的线程）造成了不必要的干扰。网络密集型服务处理中断的时间过长，以至于调度器的公平性核算机制失效。
这些问题迫使Meta对LAVD处理任务队列、时间片和CPU核算的方式进行了修改。在多个案例中，Meta添加了逻辑以更好地保持缓存局部性，或补偿那些被网络中断淹没的核心，有效地将其视为“较慢”的CPU。关键在于，这些修复不需要针对每项服务进行配置或手动设置优先级标签。这正是LAVD对Meta的核心吸引力：它根据观察到的行为进行自适应，而非依赖硬编码的规则。
工程师们也解决了一个显而易见的担忧：为Meta的服务器优化调度器，是否会损害其原有的游戏用例？他们表示，到目前为止，这些更改对Steam Deck来说要么是中性的，要么是有益的，而那些不适用的功能可以通过内核标志轻松禁用。不过，他们也承认这项实验仍在进行中。
随着Linux成为从掌上游戏机到超大规模服务器等一切设备的通用底层平台，生态系统某一角落的创新正日益渗透到其他领域。在本案例中，让一台400美元的游戏电脑保持流畅响应的调度逻辑，同样可能有助于确保数十亿条消息准时传递。这完美展示了开源软件的力量，也是一个有力的论据，证明了“水涨船高”的道理。
