Meta 工程師為 Linux 內核的 CFS 調度程序提出了共享工作隊列“swqueue”功能，該功能有助於小幅提高吞吐量性能和稍微改善延遲，特別是對於具有多個 CCX 的 AMD 系統。
今天發布的是關於 Meta 工程師一直在研究的這個 swqueue CFS 功能的“評論請求”。在他們的案例中，他們被迫在 swqueue 上工作，以提高運行 HHVM Web 服務器進程的 AMD EPYC 服務器上的吞吐量。
他們的 RFC 補丁求職信中的一些關鍵要點是:
我們注意到即使在主機過度使用時 CPU 仍然處於空閒狀態。作為回應，我們編寫了此補丁集中提出的“共享喚醒隊列”(swqueue) 功能。 swqueue 背後的想法很簡單:它使調度程序能夠通過將喚醒任務放入每個 LLC FIFO 隊列中來積極保存工作，LLC FIFO 隊列中的另一個內核可以從該隊列中拉出該隊列，然後在它運行之前將其拉出閒置的。
通過這個簡單的更改，我們能夠在 HHVM 中實現吞吐量提高 1-1.6%，以及 p95 和 p99 延遲的小幅持續改進。這些性能改進是對上述 debugfs 旋鈕帶來的好處的補充。
…
HHVM 吞吐量的 ~1-1.6% 改進同樣可見使用工作保護 sched_ext 調度程序（即使是非常簡單的調度程序，如全局 FIFO）。
在單套接字和多套接字/CCX 主機中，這可以顯著提高性能。除了在我們的內部網絡工作負載上觀察到的性能提升外，我們還觀察到常見工作負載的改進，例如運行共享喚醒隊列時的內核編譯。
…
這種形式的 swqueue 似乎為分佈在多個 CCX 上的前端 CPU 綁定工作負載提供了一個小的但明顯的勝利。原因似乎很簡單:swqueue 通過讓 CPU 從可運行任務的每個 LLC 隊列中執行 O(1) 拉取來鼓勵 CCX 內部的工作保護。如上所述，它與 SIS_NODE 互補，SIS_NODE 在喚醒路徑上搜索空閒內核。雖然這種形式的 swqueue 鼓勵工作守恆，但鑑於我們不在 swqueue 之間實施任何類型的工作竊取，它當然不能保證這一點。將來，我們可能會通過啟用 swqueue 之間的工作竊取來進一步提高 CPU 利用率，可能是在同一 NUMA 節點上的 CCX 之間。
swqueue 補丁集剛剛超過 200 行新的代碼和 RFC 補丁現已在 內核郵件列表 上進行審核。
