「概述」

在數據中心服務器或者各種云集群（后續簡稱集群）的生產環境上，部署著很多日常的在線（LC, Latency-critical service）服務。這類服務具有一定的負載不確定性，集群需要將服務器的平均利用率保持在較低的水平，使得當突發流量帶來請求洪峰時，仍有充足資源用于計算與響應，從而避免了請求堆積造成的服務癱瘓，保證用戶能夠擁有良好的體驗。但是這樣做造成了大批的空閑資源浪費，提高了維護成本。在這種條件下想要提高資源利用率，一種直接的方式是在線服務負載較低時，部署另一種任務，提高資源的利用效率。這類應用不要求有極高的響應速度，但是將耗費較大的計算資源，我們稱之為離線任務（BE, Best-effort batch）。因此各大云服務廠商引入在線離線混合部署方案來提升服務器的資源利用率，以降低云的運營成本。但事物的發展是具有兩面性的，混合部署也不例外，提升資源利用率的同時也會帶來資源隔離的問題。

本文詳細介紹并分享關于提升 CPU 資源隔離的混部技術細節：

-「CPU 搶占」：當一臺服務上同時存在在線服務、離線服務，如果不對離線服務加以限制，離線服務將會盡可能多的占用資源，從而增加在線任務的相應時延。所以本方案在同一個核上的在線（LC）服務能夠搶占壓制離線（BE）服務,最終保證在線服務的 QoS.

-「SMT 隔離控制」：同一個物理 CPU 的超線程共享核心的硬件資源，如 Cache 和計算單元。當在線任務和離線任務同時運行在一對超線程上時，會因為硬件資源爭搶出現相互干擾的情況。此時需要驅離離線任務，該 HT 核進入 idle。

在混部場景 CPU 在離線調度的實現中，存在在線作業時，我們會對離線任務進行 throttle，以確保在線任務的 CPU 資源供應。當開啟 HT 后，我們會驅離同時運行在同一個物理核且運行在不同邏輯核的離線任務。本方案的設計目標是保證在線業務服務質量前提下實現資源利用率最大化提升。因此本方案的設計是圍繞如何提升 CPU 資源利用率和保障在線業務的響應速度展開。主要包括以下兩個子特性的設計：

特性一、CPU 搶占

「（1）在線任務搶占時延保證」

為了保證在線任務能夠快速搶占離線任務，我們默認會將離線任務的調度策略設置為SCHED_IDLE，而在線任務調度策略不做修改（通常情況下在線任務的調度策略為SCHED_OTHER），當在線任務搶占離線任務時，可以快速搶占，不受限于 sched_min_granularity_ns 和sched_wakeup_granularity_ns機制限制。

「（2）在線任務絕對壓制離線任務」

當在線任務在運行時，離線任務需要停止運行，以避免和在線任務搶占 CPU 資源，因此在線任務需要盡可能地壓制離線任務，通過引入 throttle 機制對離線任務進行限制, 在一個 CPU 上同時存在在線和離線任務的場景下，將離線組對應的cfs_rq 添加到一個全局 percpu 鏈表throttle_list，從而將 CPU 資源完全讓給在線任務。具體流程如下:

圖 1 離線任務 throttle

特性二、SMT 隔離控制

由于同一個物理 CPU 上的超線程共享核心的硬件資源，比如 Cache 和計算單元。當在線任務和離線任務同時運行在一對超線程上時，相互之間會因為硬件資源爭搶，而出現相互干擾的情況。而 CFS 在設計時完全沒有考慮這個問題。其結果是，在混部場景中，在線業務的性能受損。實際測試使用 CPU 密集型 benchmark，因超線程導致的性能干擾可達 40%+。雖然 Linux 5.14 版本已經合入了 Core Scheduing，但該特性本身是為了解決利用 SMT 側信道攻擊的，避免互相不被信任的兩個進程工作在一個核的不同 SMT 上。其有幾點缺陷是我們不用該特性做 SMT 驅離的理由，首先其設計和實現過重，開銷較大（比如 core 級別的 rq lock）。其次其并不支持組調度功能，是以進程為粒度進行隔離，而我們的需求是希望對在線任務和離線任務進行隔離。為了盡可能減輕這種競爭的影響，我們讓一個核執行在線任務的時候，它對應的 MT 上不再運行離線任務；或者當一個核上有離線任務運行的時候，在線任務調度到了其對應的 HT 上時，會由該在線任務發送 IPI 將離線任務驅趕走。保證在線任務運行時不被干擾。如下圖所示：

圖 2 SMT 隔離控制方案設計

方案需要重點解決的問題

（1）離線任務 kill boost

當在線任務 100% 運行時，kill 一個離線任務，此時離線任務需要得到運行以釋放一些系統資源，但是因為當前方案在線任務會對離線任務產生絕對壓制，為此引入 kill boost 解決此問題;

離線任務所在 group 為離線 group，root group 為在線任務，當對一個離線任務進行 kill 時，將對應的離線任務移入到 root group, 從而使離線任務變為在線任務，能夠得到機會運行從而釋放資源。

（2）優先級反轉

如果在線任務和離線任務之間有共享資源(比如內核中的一些公共數據)，當離線任務因訪問共享資源而拿到鎖(抽象一下，不一定是鎖)后，如果被“絕對壓制”，一直無法運行，當在線任務也需要訪問該共享資源，而等待相應的鎖時，優先級反轉出現，導致死鎖(長時間阻塞也可能)。優先級反轉是調度模型中需要考慮的一個經典問題。

目前該方案主要分為兩個模塊，優先級反轉檢測和優先級反轉處理：

「優先級反轉檢測」：出現優先級反轉的前提的是，在線任務長時間 100%占用 CPU，導致離線任務被壓制無法釋放資源導致，基于這一特點，我們可以通過檢測離線任務是否長時間沒有得到運行來判斷是否可能存在優先級反轉流程。

「優先級反轉處理」：當檢測到優先級反轉時，對應 CPU 上的離線任務不再被在線任務壓制, 可以正常運行，在返回用戶態之前會進入睡眠流程，其中每次睡眠時間可以根據參數進行設置。當 CPU 處理完隊列中的所有任務時，就會進入 idle, 此時代表當前 CPU 恢復正常情況。代表優先級反轉問題已經解決，進入正常的在離線混跑邏輯。

任務管理

容器混部場景中，在離線任務是以 Cgroup 組的形式進行配置的，所以我們提供了 Cgroup 接口進行任務管理。對應路徑為：

/sys/fs/cgroup/cpu/xxx/cpu.qos_level

其中，cpu.qos_level文件代表當前 group 里任務的在離線屬性，默認值為 0，代表該任務為在線任務組; 若值為-1 則代表為離線任務組

于是，如果想要對任務進行管理，可以在工作節點上創建離線任務組，將離線任務的 pid 寫入到該組的 task 中，再設置對應的cpu.qos_level文件：

# echo  > /sys/fs/cgroup/cpu/xxx/tasks# echo -1 > /sys/fs/cgroup/cpu/xxx/cpu.qos_level

通過混部引擎 rubik 進行管理

在容器混合部署場景下，混部引擎 rubik 可以自動感知用戶配置的業務優先級并配置其 CPU 優先級屬性，rubik 具體的介紹和使用詳見《openEuler 資源利用率提升之道 03：rubik 混部引擎簡介》。

針對本文提到的 CPU 優先級的配置，用戶只需要在部署業務 pod 時，在 yaml 內添加volcano.sh/preemptable的 annotation 標識業務屬性，rubik 就會自動設置 pod 對應 cgroup 組的 cpu.qos_level 值。例如，如下為一個 nginx 在線業務 pod 的 yaml 文件：

# cat nginx-online.yamlapiVersion: v1kind: Podmetadata:  name: nginx-online  annotations:    volcano.sh/preemptable: "false"   # volcano.sh/preemptable為true代表業務為離線業務，false代表業務為在線業務，默認為falsespec:  containers:  - name: nginx    image: nginx    resources:      limits:        memory: "200Mi"        cpu: "1"      requests:        memory: "200Mi"        cpu: "1"

執行kubectl apply -f nginx-online.yaml部署 nginx 業務后，進入nginx-onlinePod 對應的 cgroup 路徑下，查看cpu.qos_level是否已設置（在線業務為 0，離線業務為-1）：

# cat /sys/fs/cgroup/cpu/kubepods/pod59f1cdfa-a0ad-4208-9e95-efbef3519c00/cpu.qos_level0

「總結」

本文介紹的“CPU 在離線搶占”和“SMT 隔離控制”在在離線混部場景對 CPU 資源進行管控，已經有比較好的效果了，但還有一些不夠完美的地方，如 LLC/MBA 動態調整軟件策略不夠精細，要達到較好的效果依賴硬件優先級算法，我們可以期待新的鯤鵬服務器。同時在公有云場景對鄰居干擾的消減也是很重要的，openEuler 在這方法也做了一些探索，“潮汐 affinity”技術取得了不俗的效果，也會在后續的文章中與大家見面。下一期將會分享資源利用率內存相關的技術。