來自 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 並不像看上去那麼簡單——當FS 驅動收到寫入請求時，dm-crypt 並不會立即處理它，而是將其放入“kcryptd”隊列中，這使得不是立即解析，而是在方便的時候解析。 請求從佇列傳送到 Linux Crypto API 以執行加密。 但由於 Crypto API 使用非同步執行模型，加密也不會立即執行，而是繞過另一個佇列。 加密完成後，dm-crypt 可能會嘗試使用搜尋樹對掛起的寫入請求進行排序 。 最後，一個單獨的核心執行緒再次以一定的延遲拾取累積的 I/O 請求並將它們傳送到區塊裝置堆疊。
讀取時，dm-crypt 首先向「kcryptd_io」佇列新增一個請求，以從磁碟機接收資料。 一段時間後，資料變得可用並被放置在“kcryptd”佇列中進行解密。
Kcryptd 向 Linux Crypto API 發送請求，後者非同步解密資訊。 請求並不總是經過所有佇列，但在最壞的情況下，寫入請求最多會進入佇列 4 次，讀取請求最多會進入佇列 3 次。 每次對隊列的命中都會導致延遲，這是 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