From:阿里 飛緒云巔論劍

Aliyun Linux 2 是為云上應用程序特別優化的開源操作系統，上游包括 4.19 LTS 內核、CentOS 7.6 軟件包，為阿里云基礎設施深度優化，致力于為云上用戶提供最佳體驗。

Aliyun Linux 2 4.19.24 發布之后，使用 will-it-scale testbench 性能測試發現 poll1\poll2 等系統調用，相較于 Aliyun Linux 1 4.4.95 存在一定程度的性能下降。

will-it-scale 使用每秒鐘完成的系統調用次數來衡量系統調用的性能，以下為各個內核版本下使用 will-it-scale 測試 poll1 性能的結果。

4.44.4.954.19.24

845 萬次每秒	860 萬次每秒	720 萬次每秒

Aliyun Linux 2 4.19.24 下的 poll1 性能相較于 Aliyun Linux 1 4.4.95 存在 16.2% 的性能下降，此外 poll2 也存在 7.5% 的性能下降。

結論

git bisect 發現以下 commit 影響了 poll1 的性能變化：

• 5b710f34e194 (x86/uaccess: Enable hardened usercopy)

• 236222d39347 (x86/uaccess: Optimize copy_user_enhanced_fast_string() for short strings)

• 21d375b6b34f (x86/entry/64: Remove the SYSCALL64 fast path)

will-it-scale 測得的 poll1 性能數據如下：

版本萬次/秒

4.4	845
5b710f34e194~	836
5b710f34e194	750
236222d39347~	739
236222d39347	771
21d375b6b34f~	756
21d375b6b34f	724
4.19.24	720

分析

x86/uaccess: Enable hardened usercopy

5b710f34e194 (x86/uaccess: Enable hardened usercopy)?帶來?10.29%?的性能下降。

該 commit 在 v4.8-rc2 合入主線，其在 copy_from_user()/copy_to_user() 路徑中添加 check_object_size() 檢查，以防止內核內存泄漏 (kernel memory exposure)或堆溢出 (heap overflow exploit) 等。該檢查會提升系統的安全性，但也帶來了一定的性能開銷。

x86/uaccess: Enable hardened usercopyEnables CONFIG_HARDENED_USERCOPY checks on x86. This is done both in copy_*_user() and __copy_*_user() because copy_*_user() actually calls down to _copy_*_user() and not __copy_*_user().

x86/uaccess: Optimize copy_user_enhanced_fast_string() for short strings

236222d39347 (x86/uaccess: Optimize copy_user_enhanced_fast_string() for short strings)?帶來?4.44%?的性能提升。

該 commit 在 v4.13-rc1 合入主線。

當處理器支持 ERMS (Enhanced REP MOVSB) 特性時，可以使用?rep movsb?指令優化內存拷貝操作，但是依據?Intel 64 and IA-32 Architectures Optimization Reference Manual，該優化在拷貝的數據量較大時效果明顯，而當拷貝的數據量較小時，rep movsb 指令本身存在的開銷會導致其優化效果不明顯。

因而該 commit 在 64 字節以下的內存拷貝中，將 rep movsb 替換為顯式的循環操作，從而帶來一定的性能提升。

x86/uaccess: Optimize copy_user_enhanced_fast_string() for short stringscommit 236222d39347e0e486010f10c1493e83dbbdfba8 upstream.According to the Intel datasheet, the REP MOVSB instruction exposes a pretty heavy setup cost (50 ticks), which hurts short string copy operations.This change tries to avoid this cost by calling the explicit loop available in the unrolled code for strings shorter than 64 bytes.The 64 bytes cutoff value is arbitrary from the code logic point of view - it has been selected based on measurements, as the largest value that still ensures a measurable gain.Micro benchmarks of the __copy_from_user() function with lengths in the [0-63] range show this performance gain (shorter the string, larger the gain):- in the [55%-4%] range on Intel Xeon(R) CPU E5-2690 v4 - in the [72%-9%] range on Intel Core i7-4810MQOther tested CPUs - namely Intel Atom S1260 and AMD Opteron 8216 - show no difference, because they do not expose the ERMS feature bit.

x86/entry/64: Remove the SYSCALL64 fast path

21d375b6b34f (x86/entry/64: Remove the SYSCALL64 fast path)?帶來?4.23%?的性能下降。

該 commit 在 v4.16-rc2 合入主線。該 commit 為修復 spectre 漏洞移除了 x86 64 syscall 入口的 fast path，而全部走 slow path，從而造成了一定的性能損失。

spectre 漏洞是 2018 年爆出的處理器安全漏洞，其實際利用處理器的分支預測功能所潛在的問題，利用旁路攻擊方式造成內核數據泄露。以下簡單描述該攻擊方式的原理。

當處理器執行間接跳轉指令，例如執行?call *<mem>?指令時，<mem>?表示一個內存地址，該地址處的內存保存了一個絕對地址，call 指令需要跳轉到該絕對地址。

此時 call 指令首先需要獲取?<mem>?內存的值，當該地址處的內存不處于 cache 中時，處理器就必須執行讀內存操作，由于讀內存操作相當耗時，此時處理器硬件會執行分支預測功能。

處理器硬件內部使用 BTB (Branch Target Buffer) 來緩存 (間接跳轉指令的原地址, 跳轉指令的目標地址) 這一對數據，處理器硬件的分支預測即使用 BTB 來預測當前執行的間接跳轉指令對應的目標跳轉地址。

然而該機制存在的一個問題是，同一個處理器上的不同應用程序會共用同一個 BTB，因而 spectre 漏洞的原理即是 attacker 通過用戶態程序執行特定的間接跳轉指令來訓練當前處理器的 BTB，從而使同一處理器上運行的 Linux 內核運行間接跳轉指令時，分支預測功能就會被誤導跳轉到 attacker 設計的一個特定地址上。

attacker 可以使用 eBPF 機制將 attacker 編寫的攻擊代碼注入到內核中，而通過之前描述的機制 attacker 可以使內核的間接跳轉指令在預測執行過程中，跳轉執行 attacker 注入的 eBPF 代碼，這樣通過 cache 旁路攻擊就可以獲取內核的內存數據，從而造成數據泄漏。

而 syscall fast path 的移除正是與 spectre 漏洞有關。Linux 內核中，x86 64 syscall 入口實現有兩條路徑以調用對應的系統調用。

第一條路徑是用匯編寫的 fast path，若當前沒有開啟 trace 相關的功能，則會根據系統調用號直接在 sys_call_table 中查找對應的 syscall handler 地址，并跳轉執行該 syscall handler。

call?*sys_call_table(,?%rax,?8)

另外一條是用 C 寫的 slow path，當前開啟 trace 相關功能時，只能執行 slow path 即 do_syscall_64() 函數。

由于 fast path 中使用了間接跳轉指令，容易遭受 spectre 漏洞的影響，因而在經過一系列的討論之后，社區暫時移除了 x86 syscall 的 fast path 入口，而全部走 slow paith, 而這也給系統調用的性能帶來了一定的回退。

x86/entry/64: Remove the SYSCALL64 fast path The SYCALLL64 fast path was a nice, if small, optimization back in the good old days when syscalls were actually reasonably fast. Now there is PTI to slow everything down, and indirect branches are verboten, making everything messier. The retpoline code in the fast path is particularly nasty.Just get rid of the fast path. The slow path is barely slower.

掃描下方二維碼關注"Linux閱碼場"

感謝您的耐心閱讀，請隨手轉發一下或者點個“在看”吧~

總結

以上是生活随笔為你收集整理的阿里飞绪: poll 性能回归分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。