很多 Cloudflare開發人員已發布 關於他們為優化Linux內核中的磁盤加密性能所做的工作的信息，他們提到他們已經準備好了 dm-crypt和Crypto API子系統的補丁。
有了這個， 綜合測試被允許將讀寫帶寬增加一倍， 以及 延遲減半。 在真實機器上進行測試時，加密開銷已降低到幾乎與不使用數據加密的磁盤一起使用時的水平。
對改進加密的興趣 磁盤上的數據 這是因為Cloudflare使用dm-crypt 加密用於在CDN上緩存內容的驅動器上的數據。 Dm-crypt在塊設備級別工作，並加密I / O請求以寫入和解密讀取請求，充當塊設備和文件系統驅動程序之間的一層。
評估表現 dm-crypt使用靈活的I / O測試包，se測量了使用加密分區的速度 並在位於RAM中的RAM磁盤上未加密，以消除磁盤性能波動。
對於未加密的分區，讀寫性能保持在1126MB / s，但是打開加密後，速度下降了7倍，降至147MB / s。
首先， 懷疑使用了無效的算法 在內核密碼系統中。 但是測試使用了帶有256個加密密鑰的更快的aes-xts算法，運行“ cryptsetup基準”時其性能比測試RAM磁盤時獲得的結果高兩倍以上。
實驗 帶有dm-crypt標誌 調整效果不起作用：當使用–perf-same_cpu_crypt標誌時，性能甚至下降到136MB / s，而當使用–perf-submit_from_crypt_cpus標誌時，性能僅增加到166MB / s。
更深入的分析 工作邏輯 表明dm-crypt不是那麼簡單 好像。
從FS控制器接收到寫請求時，dm-crypt不會立即處理它，而是將其放在“ kcryptd”隊列中，但不會立即理解，但是會發生適當的時間。 該請求從隊列發送到Linux Crypto API進行加密。
首先閱讀時，dm-crypt將“ kcryptd_io”排隊 從本機接收數據的請求。 然後 一段時間後，數據可用 他們排隊“解密”進行解密。
Kcryptd向Linux加密API發送請求，該API異步解密信息。 請求並不總是經過所有隊列，但在最壞的情況下， 在隊列上最多設置4次寫入請求 讀取請求最多3次。 尾巴的每一次撞擊都會導致延誤， 這是dm-crypt性能顯著下降的主要原因。
考慮到現代驅動器已經變得更快，更智能，Linux內核中的資源分配系統已經過修訂， 一些子系統已經過重新設計，Cloudflare工程師為dm-crypt添加了新的操作模式，從而避免了使用其他隊列和異步調用。
該模式由單獨的“ force_inline”標誌啟用，並將dm-crypt轉換為簡單代理的形式，該代理對傳入的請求進行加密和解密。 通過明確選擇加密算法，優化了與Crypto API的交互 它們以同步模式運行，不使用請求隊列。
在測試真實服務器上的負載時，新部署顯示的性能非常接近無需加密即可運行的配置，並且在具有Cloudflare緩存的服務器上包含加密不會影響響應速度。
在將來，Cloudflare計劃將準備好的補丁轉移到主要的Linux內核，但在此之前必須對其進行修改，因為它們已針對特定負載進行了優化，並且無法涵蓋所有應用領域。
來源： https://blog.cloudflare.com