io_uring 如何超越 libaio：跨 Linux 核心版本的效能分析與意外的 IOMMU 陷阱

背景

這篇文章探討了 Linux 系統中兩種非同步 I/O 介面——傳統的 libaio 與較新的 io_uring——在不同核心版本間的效能演進。作者透過 fio 工具在多個核心版本上進行 4K 隨機寫入測試，發現 io_uring 不僅全面超越 libaio，其效能更隨核心更新顯著提升，但也意外揭露了 IOMMU 開啟後對 I/O 吞吐量造成的巨大衝擊。

社群觀點

在 Hacker News 的討論中，社群成員對這項測試結果展現了高度興趣，特別是針對 IOMMU 導致的效能衰退展開了深入交流。原作者 eivanov89 指出，雖然 io_uring 帶來了近兩倍的效能增益，但核心版本更新後預設開啟 IOMMU 卻造成了約 30% 的效能回歸。針對此點，jcalvinowens 詢問了 IOMMU 的無效化機制是採取嚴格還是延遲模式，作者回應雖然預設應為延遲模式，但他建議在追求極致效能的場景下，應使用 passthrough 模式完全繞過翻譯層。

關於測試負載的選擇，有留言質疑為何僅針對 4K 隨機寫入進行測試。作者解釋這是因為資料庫管理系統（DBMS）常見此類模式，且 NVMe 裝置的寫入速度通常較快，更容易觀察到軟體層面的延遲。然而，menaerus 認為混合讀寫負載可能更具參考價值，因為純寫入通常只代表資料攝取階段。對此，作者坦言混合負載在 NVMe 上容易因裝置內部的垃圾回收機制導致延遲不穩定，為了維持軟體開銷比較的純粹性，才選擇單一負載。他進一步分析，io_uring 的優勢在於透過共享環與預註冊資源減少了控制結構的複製，且其系統調用延遲比 AIO 更具預測性。

效能專家 tanelpoder 則從硬體中斷的角度提供了深度見解。他認為 IOMMU 的開銷可能源於中斷重映射帶來的延遲，並建議透過監測中斷計數與 IRQ 處理時間的直方圖來進一步釐清。他指出，即使在 IOPOLL 模式下避開了中斷開銷，IOMMU 的 DMA 翻譯成本依然存在。此外，討論也延伸到了雲端成本與安全性的權衡。singron 比較了自行維護高效能 NVMe 裝置與 AWS EBS 服務的成本差異，指出在極高 IOPS 需求下，雲端硬碟的成本將變得極其驚人。而在安全性方面，雖然 IOMMU 會損耗效能，但它是防止惡意 PCIe 裝置透過 DMA 存取任意實體記憶體的重要防線，對於非專用硬體的環境至關重要。

延伸閱讀

• Linux Hiding Interrupt CPU Usage: tanelpoder 撰寫關於 Linux 如何隱藏中斷 CPU 使用率的技術文章，內含如何利用火焰圖識別中斷開銷的技巧。
• Thunderclap: 劍橋大學關於 IOMMU 安全漏洞的研究，探討即便開啟隔離，部分 DMA 攻擊仍可能穿透防護。