該調(diào)度器最初是為了防止 Valve 的 Steam Deck 上掉幀而開發(fā)的

當Meta為其龐大的服務(wù)器群尋找更好的Linux處理器調(diào)度器時，它并非從數(shù)據(jù)中心開始。相反，它最初是從一臺掌上游戲電腦開始的。在最近于東京舉辦的Linux管道工大會上的一場技術(shù)演講中，Meta工程師詳細介紹了他們?nèi)绾螌CX-LAVD——一款最初由Valve為Steam Deck開發(fā)的低延遲Linux調(diào)度器——部署在運行從消息后端到緩存服務(wù)的生產(chǎn)服務(wù)器上。令人驚訝的結(jié)論是：一個設(shè)計用來保持游戲在負載下響應(yīng)的調(diào)度器，也非常適合大規(guī)模數(shù)據(jù)中心工作負載。

從高層次來說，CPU 調(diào)度器決定哪些程序可以在哪些 CPU 核心上運行，以及何時運行。Linux的默認調(diào)度器必須在手機、筆記本、臺式機、服務(wù)器等任何地方工作——這使得它極為保守。Meta的挑戰(zhàn)不同：它運行著擁有數(shù)百個CPU核心的龐大機器，工作負載極其多樣化，最重要的是嚴格的延遲目標。在那種環(huán)境下，“到處都夠好”往往不夠好。Meta 希望為每個服務(wù)都打造定制調(diào)度器，而是更接近全艦隊默認的“一刀切”調(diào)度器，能夠自動適應(yīng)而無需手動配置。這就是SCX-LAVD發(fā)揮作用的地方。

SCX-LAVD 基于 sched_ext 構(gòu)建，這是一個相對較新的 Linux 框架，使得替代調(diào)度器能夠在不需重大內(nèi)核修改的情況下插入內(nèi)核。簡單來說，sched_ext讓企業(yè)能夠安全且漸進地嘗試不同的調(diào)度策略，而無需分支Linux或維護龐大的補丁集。

LAVD本身代表Latency-Aware虛擬截止時間，如果你留心，這個名字就透露了游戲的秘密。調(diào)度器不再依賴靜態(tài)優(yōu)先級或手動提示，而是持續(xù)觀察任務(wù)的行為、睡眠、喚醒和阻塞的頻率，然后估算哪些任務(wù)對延遲敏感。這些任務(wù)會提前獲得“虛擬截止日期”，提高它們在系統(tǒng)繁忙時及時完成的可能性。

這種做法最初是出于游戲的啟發(fā)。在Steam Deck上，錯過排程截止時間會導(dǎo)致幀數(shù)掉落、卡頓或輸入響應(yīng)遲緩。事實上，在數(shù)據(jù)中心，同樣的故障模式表現(xiàn)為網(wǎng)絡(luò)請求緩慢、消息延遲或服務(wù)級目標未達。完全不同的應(yīng)用，但根本上是同一個根本問題。

在演講中，Meta的工程師們描述了在將LAVD擴展到服務(wù)器級硬件時出現(xiàn)的幾個挑戰(zhàn)。在擁有數(shù)十個核心共享單一調(diào)度隊列的機器上，爭用成為瓶頸。釘頂任務(wù)，即只能在某一特定核心上運行的線程，造成了不必要的干擾。網(wǎng)絡(luò)密集型服務(wù)花了大量時間處理中斷，以至于調(diào)度者的公平性會計失效。

這些問題迫使LAVD對任務(wù)隊列、時間片和CPU計費的處理方式進行了調(diào)整。在多個情況下，Meta 添加了邏輯以更好地保持緩存本地性，或補償被網(wǎng)絡(luò)中斷淹沒的核心，實際上將其視為“較慢”的 CPU。關(guān)鍵是，這些修復(fù)不需要按服務(wù)配置或手動優(yōu)先標記。這就是LAVD對Meta的核心吸引力：它根據(jù)觀察到的行為進行調(diào)整，而非硬編碼規(guī)則。

工程師們還回應(yīng)了一個顯而易見的問題：為Meta服務(wù)器優(yōu)化調(diào)度器是否會損害其最初的游戲用途？他們表示，到目前為止，這些變化對Steam Deck來說要么是中立的，要么是有益的，不適用的功能可以用內(nèi)核標志直接禁用。不過，他們承認實驗仍在進行中。

隨著Linux成為從掌機到超大規(guī)模服務(wù)器的通用基礎(chǔ)，生態(tài)系統(tǒng)某一角落的創(chuàng)新正逐漸滲透到其他角落。在這種情況下，同樣的調(diào)度邏輯能讓一臺400美元的游戲電腦感覺流暢，也可能幫助數(shù)十億條消息按時發(fā)送。這完美展示了開源軟件的力量，也是一個有力的論證，說明“漲潮會讓所有船只都高漲”。