LAVD 排程器補上 cgroup cpu.max 與任務大小感知負載平衡
LWN.net（OSPM 2026 第二天報告） · 2026-10-07
scx_lavd 原本只為 Steam Deck 上的 Windows 遊戲調校，現在開始補伺服器必備的兩塊：cgroup v2 的 cpu.max 頻寬控制，以及看任務大小的跨 LLC 負載平衡。它不再只是遊戲排程器，而是被 Changwoo Min 與 Gavin Guo 當成潛在的「預設機群排程器」在推。
背景：為什麼遊戲排程器不能直接上伺服器
LAVD 的全名是 Latency-criticality Aware Virtual Deadline，依任務的喚醒與阻塞頻率、執行時間估算延遲關鍵度，再決定虛擬期限與時間片。README 自己寫明它「mainly targets single CCX / single-socket systems」。
Min 在 2025 年 12 月的投影片已把「8 核到 100 核以上、單一 LLC 到 10 個以上 LLC domain、補上 cpu.max」列為下一步。
核心改動一：把 cpu.max 的成本移出 dispatch 路徑
核心現行的 cpu.max 有三處成本會隨 cgroup 層級變深而增加：任務選擇要走巢狀紅黑樹、節流偵測每次 dispatch 都可能往上爬階層、補充額度每群組兩個 timer。Min 做的 lib/cgroup_bw 可被任何 sched_ext 排程器連結，scx_lavd 是第一個使用者。
| 面向 | 核心現行實作 | lib/cgroup_bw |
|---|---|---|
| 任務選擇 | 巢狀紅黑樹，成本隨深度線性成長 | 未節流任務留在一般 DSQ，維持 O(log N) |
| 節流檢查 | 各 CPU 向群組額度池借 5ms 時間片，需往上走階層 | 熱路徑只讀一個旗標，無鎖、無 atomic |
| 補充額度 | 每群組兩個 timer | period 統一為 100ms，全系統兩個 timer |
代價是精確度模型改了：群組最多可超支一個記帳區間，超支記為債務，從下一期預算精確扣除。Min 強調長期平均用量仍會收斂到設定的 quota。為了縮小偵測延遲，函式庫用指數加權移動平均預測群組何時撞線，提前觸發記帳 timer。
在 2 路、96 核（192 CPU）的 AMD EPYC 上跑 stress-ng --cpu，cgroup 深度從 1 增加到 32 時，EEVDF 的排程開銷從約 2 個 CPU 增加到約 5 個，scx_lavd 維持約 2 個。深度 32、負載 125% 時，EEVDF 超過 10 個 CPU，LAVD 仍約 2 個。
這組數字有保留：Min 承認基準線早於 2025 年 9 月核心對 cpu.max 節流的重做（延後到返回 user space 時才節流，並已有債務結轉），對新核心的差距會縮小，需要重測。
核心改動二：看任務大小與 CPU 容量的負載平衡
LAVD 每個 LLC domain 有一條共用 DSQ，每 10ms 依排隊負載相對系統平均，把 domain 指派為 stealer 或 stealee。Guo 指出舊平衡器有三個問題。
- 負載指標失真：以使用率加上縮放後的佇列長度計算，十個短任務的 domain 看起來比兩個長任務的更忙。
- 沒有搬移額度：許多 CPU 同一輪一起去抽乾同一個過載 domain，只靠機率閘門抑制驚群。
- 不分任務型別：大任務可能落到小核。
新設計把指標換成 queued_load_invr + util_invr，前者是 domain 內任務「大小」總和而非個數，執行時間依 CPU 容量與頻率換算，因此 P 核、E 核、LP-E 核的負載可直接比較。每個 domain 依容量比例分到公平份額（容量佔 40% 就應承擔 40% 的排隊負載）。搬移受對稱 50% 額度限制：stealee 只放出超出份額部分的一半，stealer 只吸收低於份額部分的一半，避免一次補平後 stealee 變成下一個 stealer。
以 schbench 喚醒延遲、各 6 次量測，與 scx_lavd main 相比：
| 平台 | p99 | p99.9 |
|---|---|---|
| 14 CPU Meteor Lake（異質） | 5,867µs → 5,613µs（-4.3%） | 9,899µs → 9,195µs（-7.1%） |
| 192 CPU AMD EPYC 9R14（同質） | 5,867µs → 5,741µs（-2.1%） | 7,297µs → 6,777µs（-7.1%） |
改善幅度不大，但在同質伺服器上 p99.9 仍降 7.1%，說明搬移額度與任務大小指標獨立於容量感知也有效。已知缺口是 SMT：目前把 P 核 domain 的邏輯 CPU 視為彼此獨立，Guo 承認這會高估容量。
影響範圍
- 跑容器或多租戶的機器：若評估 sched_ext 排程器，要確認它是否真的支援
cpu.max。多數自訂排程器過去沒有，quota 會形同虛設。lib/cgroup_bw讓其他 sched_ext 排程器也能接上。 - 深 cgroup 階層的 Kubernetes 節點：EEVDF 的開銷隨深度增加，是這次實驗最直接對應的場景，但請先對自己的核心版本重測。
這些仍是報告階段的成果，來源未說明哪個 scx 版本已合併。
原始來源：LWN：Reports from OSPM 2026, day two、Min 2025-12-12 投影片、scx_lavd README