一、背景：性能之戰(zhàn)

“不服跑個分”已經(jīng)淪為手機行業(yè)的調(diào)侃用語，但是實話實說，在操作系統(tǒng)領(lǐng)域“跑分”確實是最重要的評價方式之一。比如 Linux 內(nèi)核社區(qū)常常以跑分軟件得分，來評價一個優(yōu)化補丁的價值。甚至還有 phoronix 這樣專注于 Linux 跑分的媒體。而且今天我還想說一點，讓軟件跑分高，這是實力的體現(xiàn)，是建立在對內(nèi)核的深刻理解基礎(chǔ)上的。本文的故事就源于一次日常的性能優(yōu)化分析。我們在評估自動化性能調(diào)優(yōu)軟件 tuned 的時候，發(fā)現(xiàn)它在服務(wù)器場景，對 Linux 內(nèi)核調(diào)度器相關(guān)的參數(shù)做了一些微小的修改，但是這些修改卻很大程度改善了 hackbench 這款跑分軟件的性能。是不是很有意思？讓我們一起來一探究竟。

本文將從幾個方面展開，并重點介紹黑體字部分：

相關(guān)知識簡介
hackbench 工作模式簡介
hackbench 性能受損之源
雙參數(shù)優(yōu)化
思考與拓展

二、相關(guān)知識簡介

2.1 CFS調(diào)度器

Linux 中大部分（可以粗略認為是實時任務(wù)之外的所有）線程/進程，都由一個叫 CFS（完全公平調(diào)度器）的調(diào)度器進行調(diào)度，它是 Linux 最核心的組件之一。（在Linux中，線程和進程只有細微差別，下文統(tǒng)一用進程表述）

CFS 的核心是紅黑樹，用于管理系統(tǒng)中進程的運行時間，作為選擇下一個將要運行的進程的依據(jù)。此外，它還支持優(yōu)先級、組調(diào)度（基于我們熟知的 cgroup 實現(xiàn)）、限流等功能，滿足各種高級需求。CFS 的詳細介紹。

2.2 hackbench

hackbench 是一個針對 Linux 內(nèi)核調(diào)度器的壓力測試工具，它的主要工作是創(chuàng)建指定數(shù)量的調(diào)度實體對（線程/進程），并讓它們通過 sockets/pipe 進行數(shù)據(jù)傳輸，最后統(tǒng)計整個運行過程的時間開銷。

2.3 CFS 調(diào)度器參數(shù)

本文重點關(guān)注以下兩個參數(shù)，這兩個參數(shù)也是影響 hackbench 跑分性能的重要因素。系統(tǒng)管理員可以使用 sysctl 命令來進行設(shè)置。

最小粒度時間：kernel.sched_min_granularity_ns

通過修改 kernel.sched_min_granularity_ns，可以影響 CFS 調(diào)度周期（sched period）的時間長短。例如：設(shè)置kernel.sched_min_granularity_ns = m，當系統(tǒng)中存在大量可運行進程時，m 越大，CFS 調(diào)度周期就越長。

如圖 1 所示，每個進程都能夠在 CPU 上運行且時間各有長短，sched_min_granularity_ns 保證了每個進程的最小運行時間（優(yōu)先級相同的情況下），sched_min_granularity_ns 越大每個進程單次可運行的時間就越長。

圖 1：sched_min_granularity_ns 示意圖

喚醒搶占粒度：kernel.sched_wakeup_granularity_ns

kernel.sched_wakeup_granularity_ns 保證了重新喚醒的進程不會頻繁搶占正在運行的進程，kernel.sched_wakeup_granularity_ns 越大，喚醒進程進行搶占的頻率就越小。

如圖 2 所示，有 process-{1,2,3} 三個進程被喚醒，因為 process-3 的運行時間大于 curr（正在 CPU 上運行的進程）無法搶占運行，而 process-2 運行時間小于 curr 但其差值小于 sched_wakeup_granularity_ns 也無法搶占運行，只有 process-1 能夠搶占 curr 運行，因此 sched_wakeup_granularity_ns 越小，進程被喚醒后的響應(yīng)時間就越快（等待運行時間越短）。

圖 2：sched_wakeup_granularity_ns 示意圖

三、hackbench 工作模式簡介

hackbench 工作模式分為 process mode 和 thread mode，主要區(qū)別就是以創(chuàng)建 process 還是 thread 為基礎(chǔ)來進行測試，下面以 thread 來進行介紹。

hackbench 會創(chuàng)建若干線程（偶數(shù)），均分為兩類線程：sender 和 receiver
并將其劃分為 n 個 group，每個 group 包含 m 對 sender 和 receiver。
每個 sender 的任務(wù)就是給其所在 group 的所有 receiver 輪流發(fā)送 loop 次大小為 datasize 的數(shù)據(jù)包
receiver 則只負責接收數(shù)據(jù)包即可。
同一個 group 中的sender 和 receiver 有兩種方式進行通信：pipe 和 local socket（一次測試中只能都是 pipe 或者 socket），不同 group 之間的線程沒有交互關(guān)系。
通過上面 hackbench 模型分析，可以得知同一個 group 中的 thread/process 主要是 I/O 密集型，不同 group 之間的 thread/process 主要是 CPU 密集型。

圖 3: hackbench 工作模式

主動上下文切換：

對于 receiver，當 buffer 中沒有數(shù)據(jù)時，receiver 會被阻塞并主動讓出 CPU 進入睡眠。
對于 sender，如果 buffer 中沒有足夠空間寫入數(shù)據(jù)時， sender 也會被阻塞且主動讓出 CPU。
因此，系統(tǒng)中"主動上下文切換"是很多的，但同時也存在“被動上下文切換”。后者會受到接下來我們將要介紹的參數(shù)影響。

四、hackbench性能影響之源

在hackbench-socket 測試中，tuned修改了 CFS 的 sched_min_granularity_ns 和 sched_wakeup_granularity_ns 兩個參數(shù)，導致了性能的顯著區(qū)別。具體如下：

接下來我們調(diào)整這兩個調(diào)度參數(shù)來進行進一步的深入分析。

五、雙參數(shù)優(yōu)化

注：為了簡介表達下面會以 m 表示 kernel.sched_min_granularity_ns，w 表示 kernel.sched_wakeup_granularity_ns

為了探索雙參數(shù)對于調(diào)度器的影響，我們選擇每次固定一個參數(shù)，研究另一個參數(shù)變化對于性能的影響，并使用系統(tǒng)知識來解釋這種現(xiàn)象背后的原理。

5.1 固定 sched_wakeup_granularity_ns

圖 4: 固定 w，調(diào)整m

在上圖中我們固定了參數(shù) w 并根據(jù)參數(shù) m 變化趨勢其劃分為三個部分：區(qū)域A（1ms～4ms），區(qū)域B（4ms～17ms），區(qū)域C（17ms～30ms）。在區(qū)域A中四條曲線均呈現(xiàn)一個極速下降的趨勢，而在區(qū)域B中四條曲線都處于一種震蕩狀態(tài)，波動較大，最后在區(qū)域C中四條曲線都趨于穩(wěn)定。

在第二節(jié)相關(guān)知識中可以知道 m 影響著進程的運行時間，同時也意味著它影響著進程的“被動上下文切換”。

對于區(qū)域A而言，搶占過于頻繁，而大部分搶占都是無意義的，因為對端無數(shù)據(jù)可寫/無緩沖區(qū)可用，導致大量冗余的“主動上下文切換“。此時較大的 w 能讓 sender/receiver 有更多的時間來寫入數(shù)據(jù)/消耗數(shù)據(jù)來減少對端進程無意義的“主動上下文切換“。
對于區(qū)域B而言，隨著 m 的增加漸漸滿足 sender/receiver 執(zhí)行任務(wù)的時間需求能夠在緩沖區(qū)寫入/讀出足夠的數(shù)據(jù)，因此需要較小的 w 來增加喚醒進程的搶占幾率，讓對端進程能夠更快的響應(yīng)處理數(shù)據(jù)，減少下一輪調(diào)度時的“主動上下文切換”。
對于區(qū)域C而言，m已經(jīng)足夠大，已經(jīng)幾乎不會有“被動上下文切換”發(fā)生，進程會在執(zhí)行完任務(wù)之后進行“主動上下文切換”等待對端進程進行處理，此時 m 對性能的影響就很小了。

5.2 固定 sched_min_granularity_ns

圖 5: 固定 m，調(diào)整w

在上圖中我們固定了參數(shù) m，同樣劃分了三個區(qū)域：

在區(qū)域A中，同樣存在圖 4 中的現(xiàn)象，較大 m 受 w 的影響較小，而較小的 m 隨著 w 的增大性能會越來越好。
在區(qū)域B中，中等大小的 m（8ms/12ms）進程還是存在較多“被動上下文切換”，并且其中的進程已經(jīng)處理了相當一部分數(shù)據(jù)期望對端進程能夠盡快的響應(yīng)處理，因此較大 w 會嚴重影響中等大小 m 的性能。
在區(qū)域C中圖5和圖4表現(xiàn)一致都是趨于穩(wěn)定，因為 w 過大時幾乎不會發(fā)生喚醒搶占，因此這時單純 w 值的變化對性能的影響并不大，但是過大的 w 對于中等大小的 m 則會造成性能問題（原因同上條）。

5.3 性能趨勢總覽

下面是一個實驗數(shù)據(jù)的熱力總覽圖，來直觀展示 m 和 w 之間的制約關(guān)系，以供需要的同學參考分析。三個區(qū)域和圖 4、圖 5 的區(qū)域會略有不同。

圖 6：總覽圖

5.4 最優(yōu)雙參數(shù)（對于 hackbench ）

從上面兩節(jié)的分析可知對于 hackbench 這樣帶有“主動上下文切換”的場景可以選擇較大的 m（例如：15~20ms）。
在pipe/socket 雙向通信的場景中，對端的響應(yīng)時間會對影響進程的下一次處理，為了讓對端進程能夠及時響應(yīng)可以選擇一個中等大小的 w（例如：6～8ms）來獲取較高的性能。

六、思考與擴展

在桌面場景中，應(yīng)用更偏向于交互型，應(yīng)用的服務(wù)質(zhì)量也更多的體現(xiàn)在應(yīng)用對于用戶操作的響應(yīng)時間，因此可以選擇較小的 sched_wakeup_granularity_ns 來提高應(yīng)用的交互性。
在服務(wù)器場景中，應(yīng)用更偏向于計算處理，應(yīng)用需要更多的運行時間來進行密集計算，因此可以選擇較大的 sched_min_granularity_ns，但是為了防止單個進程獨占 CPU 過久同時也為了能夠及時處理客戶端請求響應(yīng)，應(yīng)該選擇一個中等大小的 sched_wakeup_granularity_ns。
在 Linux 原生內(nèi)核中 m 和 w 的默認參數(shù)被設(shè)置為適配桌面場景，Anolis OS的用戶，需要根據(jù)自己部署的應(yīng)用的場景，屬于桌面型還是服務(wù)器型，來選擇內(nèi)核參數(shù)，或者使用tuned的推薦配置。而 hackbench 作為一個介于桌面和服務(wù)器間的應(yīng)用，也可以作為配置的參考。