來自 Cloudflare 的開發人員 關於核心中磁碟加密效能最佳化工作的最新進展 Linux因此，準備了以下內容： 對於子系統 Crypto API，使得綜合測試中的讀寫吞吐量增加一倍以上，並將延遲減半。 在真實硬體上進行測試時，加密開銷幾乎減少到使用未加密資料的磁碟時觀察到的水平。
Cloudflare 使用 dm-crypt 來加密用於在 CDN 上快取內容的儲存裝置上的資料。 Dm-crypt 在區塊裝置層級運行，加密寫入 I/O 請求並解密讀取請求，充當區塊裝置和檔案系統驅動程式之間的層。
使用該套件評估 dm-crypt 的性能 我們測量了位於 RAM 中的 RAM 磁碟上使用加密和未加密分割區的速度，以消除磁碟效能的波動並專注於程式碼效能。 對於未加密的分割區，讀寫效能仍保持在1126MB/s，但啟用加密後速度有所下降 7次 達到 147 MB/s。
起初，人們懷疑在核心密碼系統中使用了低效演算法。 但測試使用了最快的演算法 aes-xts，具有 256 個加密金鑰，其運行「cryptsetup benchmark」時的效能比測試 RAM 磁碟時獲得的結果高出兩倍多。 使用dm-crypt 標誌進行效能調整的實驗沒有產生結果：當使用「--perf-same_cpu_crypt」標誌時，效能甚至下降到136 MB/s，而當指定「--perf-submit_from_crypt_cpus」標誌時，它僅增加至 166 MB/秒。
對邏輯的深入分析表明，dm-crypt 並不像表面看起來那麼簡單。當檔案系統驅動程式發出寫入請求時，dm-crypt 不會立即處理，而是將其放入名為「kcryptd」的佇列中。該隊列中的請求也不會立即解析，而是在適當的時機進行解析。之後，該請求會被傳送到… Linux Crypto API 執行加密操作。然而，由於 Crypto API 使用非同步執行模型，加密操作不會立即執行，而是繞過另一個佇列。加密完成後，dm-crypt 可以嘗試使用搜尋樹對待處理的寫入請求進行排序。 。 最後，一個單獨的核心執行緒再次以一定的延遲拾取累積的 I/O 請求並將它們傳送到區塊裝置堆疊。
讀取時，dm-crypt 首先向「kcryptd_io」佇列新增一個請求，以從磁碟機接收資料。 一段時間後，資料變得可用並被放置在“kcryptd”佇列中進行解密。
Kcryptd 向 Linux dm-crypt 是一種非同步解密資料的加密 API。請求並非總是會遍歷所有佇列，但在最壞的情況下，寫入請求最多會被佇列阻塞四次，讀取請求最多會被阻塞三次。每次佇列阻塞都會引入延遲，這是導致 dm-crypt 效能顯著下降的關鍵原因。
使用隊列是因為需要在發生中斷的情況下工作。 2005 年，當 dm-crypt 目前基於佇列的操作模型實作時，Crypto API 還不是非同步的。 Crypto API轉為非同步執行模型後，本質上開始使用雙重保護。 也引入了佇列來節省內核堆疊的消耗，但在 2014 年增加佇列之後，這些最佳化就失去了相關性。 引入了額外的佇列“kcryptd_io”來克服大量請求到達時導致等待記憶體分配的瓶頸。 2015年，引入了額外的排序階段，因為多處理器系統上的加密請求可能會無序完成（而不是順序訪問磁碟，而是以隨機順序進行訪問，並且CFQ調度程序無法有效工作）。 目前，當使用SSD硬碟時，排序已經失去了意義，核心中不再使用CFQ調度器。
隨著現代儲存設備變得越來越快、越來越智能，核心中的資源分配系統也隨之改變。 Linux Cloudflare工程師對系統進行了審查，並重新設計了一些子系統。 dm-crypt 有一個新的操作模式，消除了不必要的佇列和非同步呼叫的使用。 此模式由單獨的標誌「force_inline」啟用，並將 dm-crypt 引入加密和解密傳入請求的簡單代理的形式。 透過明確選擇在同步模式下運行且不使用請求佇列的加密演算法，優化了與 Crypto API 的交互。 為了與 Crypto API 同步工作，有 使用FPU/AES-NI加速並直接轉送加解密請求的模組。
因此，在測試 RAM 磁碟時，dm-crypt 的效能可以提高一倍以上 - 效能從 294 MB/s (2 x 147 MB/s) 增加到 640 MB/s，非常接近裸加密的效能（696 MB /秒）。
在真實伺服器上進行的負載測試中，新實現方案的效能與未加密的配置非常接近，並且在啟用 Cloudflare 快取的伺服器上啟用加密對回應時間沒有任何影響。 Cloudflare 計劃在未來將這些補丁整合到核心程式碼中。 Linux但在此之前，它們需要重新設計，因為它們是針對特定工作負載進行最佳化的，並未涵蓋所有應用領域，例如低功耗嵌入式裝置上的加密。
來源： opennet.ru
