【摘要】

最近的高性能存儲設備暴露了現有軟件棧的低效，因而催生了對I/O棧的改進。Linux內核的最新API是io_uring。作者提供了第一個針對io_uring的深度研究，并且和libaio、SPDK比較，探討它的下性能和優缺點。根據作者的發現，（1）輪詢能極大影響性能（2）只要CPU核足夠多，io_uring可以提供和SPKD接近的性能（3）在多核CPU和多設備場景下擴展需要仔細的考慮并且需要一個混合方案。最后，作者為存儲密集的應用開發者提供了設計指導。

【三種API簡介】

1、libaio

傳統的同步I/O接口包括read()、write()、pread()、pwrite()等，線程開始I/O操作后立刻進入阻塞狀態，直到I/O請求完成。而使用異步I/O接口，如aio，線程把I/O請求發送給內核后可以繼續做其他工作，直到內核把I/O請求完成的信號發送給線程。通常，異步I/O接口效率更高，其中的核心系統調用是io_submit（用于提交I/O請求）和io_getevents（用于獲得完成的I/O請求）。然而，在每個I/O操作中，libaio要依賴兩個系統調用，而且使用中斷的方式通知I/O請求的完成，這導致libaio的單個I/O性能并不好，如下圖。

2、SPDK

SPDK是Linux的高性能API。它在用戶空間映射了PCIe寄存器以配置CQ和SQ，用戶通過輪詢CQ來捕獲I/O請求的完成，而不需要中斷和系統調用。SPDK的缺點是它很復雜，而且相對于libaio適用范圍很窄。SPDK不支持文件系統，也無法利用內核存儲服務，如訪問控制、調度、QoS和配額管理。

3、io_uring

io_uring中和了上述兩類API的優缺點。它在用戶空間實現了兩個環形數據結構，同時內核可以訪問它們，類似于NVMe的CQ和SQ，submission ring存儲了用戶提交的I/O請求，completion存儲了I/O請求的完成結果。用戶可以不通過系統調用插入和檢索兩個環。

io_uring提供的I/O機制有三種，如下圖：

默認模式下，用戶可以通過io_uring_enter系統調用通知內核新請求已經提交到SQ中。用戶使用同一個io_uring_enter系統調用等待I/O請求完成。io_uring_enter支持中斷模式（a）和輪詢模式（b）。當然，因為用戶也可以訪問CQ，所以用戶可以自己輪詢CQ等待I/O請求完成，而不使用任何系統調用。并且，io_uring也可以使用一個內核線程輪詢SQ，這樣在整個I/O操作中不會使用任何系統調用（c）。

【性能測試分析】

實驗使用fio生成4KB隨機讀負載，不使用page cache。純讀負載能達到更高的IOPS，而高IOPS有助于分析不同API的可擴展性趨勢和每個I/O操作的開銷。除了io_uring外，其他API均使用默認配置。io_uring的配置如下：

（1）iou：上圖（a）的配置（默認的fio參數）

（2）iou+p：上圖（b）的配置（fio參數是hipri）

（3）iou+k：不使用系統調用，即使用內核線程輪詢I/O的提交，同時應用輪詢I/O的完成（fio的參數是sqthread_poll）

環境配置如下表：

P.S. 雖然io_uring里提供了io_uring_enter作為提交I/O請求和捕獲完成的I/O請求的統一接口，但FIO里面還是分開使用了（即調用了兩次io_uring_enter）。

1、理解輪詢

作者使用單個fio job、單個NVMe驅動和單個CPU，在不同隊列深度下，測試三種API（libaio、io_uring和SPDK）的KIOPS，如下圖：

每個IOPS下對應的延遲中位數如下圖：

平均每個I/O操作進行的系統調用個數如下圖：

① 可知，iou+k的KIOPS僅僅13，比其他API少一個數量級。因為此時fio線程和內核輪詢線程共享一個CPU，減少了FIO每秒處理的I/O請求的數量。同時，iou+k的延遲是8ms，比其他API慢1~2個數量級。iou+k的延遲不隨KIOPS的變化而變化，因為此時的延遲取決于CPU資源的競爭，而非排隊等待。

當CPU數量增加到2時，iou+k的性能完全恢復了，如下圖：

每個KIOPS對應的延遲中位數為：

此時，iou+k的性能僅次于SPDK：最大帶寬比SPDK小18%，延遲和SPDK相當。

②SPDK在所有場景下性能最好，也是唯一達到驅動帶寬上限的API。SPDK和iou+k的區別在于，iou+k使用兩個線程訪問同一個變量，會產生原子訪問和緩存失效的開銷，而SPDK使用一個線程，能更加充分的利用資源。

③ 當IOPS較小時，iou+p的性能和SPDK接近，因為隊列深度較小時，系統調用的開銷還不足以成為性能瓶頸，此時系統態輪詢和用戶態輪詢的性能接近。類似的還有iou和libaio，當隊列深度小于16時，二者KIOPS和延遲都很接近，當隊列深度大于16后，iou的KIOPS和延遲比libaio要好——因為iou使用的系統調用比libaio少，所以可以更加充分的利用CPU資源。

當隊列深度小于16時，iou的系統調用比iou+p少，但延遲比iou+p高。原因是，隊列較淺時，fio的隊列很快會被填滿，而當隊列滿時，fio會等待至少一個請求完成再進行下一步動作。此時，雖然中斷比較慢，但iou可能會一次處理較多完成的請求，而輪詢則是檢測到一個請求完成就退出，從而錯失了批量處理多個完成的請求的機會。當隊列深度增加時，兩個API最后都趨向于每個I/O請求只使用1個系統調用。

iou和libaio的最大區別是，iou多了一個提交隊列（SQ），這就是它具有批處理能力的原因。

2、不同的CPU-設備比

作者進一步分析了對于iou+k，每個驅動需要多少個CPU以獲得最佳性能。此時，作者使用了J=5個FIO job測試，每個job運行在不同的驅動上，隊列深度為128，C代表CPU的數目，本次實驗中，分別測試了C=J，C=J+1，C=J+2和C=J*2的情況。

注意，在iou+k中，內核會為每個job產生一個內核線程以輪詢SQ獲得提交的請求。

實驗結果如下圖：

可見，除了iou+k，其他API的帶寬表現和CPU-設備比無關。而iou+k需要兩倍于驅動數的CPU才能達到最好的性能——即每個線程需要一個單獨的CPU來輪詢。糟糕的是，當CPU數不是最佳時，iou+k的KIOPS是最低的。這一實驗結果揭示了iou+k要實現高性能的隱藏開銷，而其他測試忽略了這一點。

3、可擴展性

作者控制job從1到20，以測試不同API的可擴展性。每個job訪問不同的驅動，設置CPU數C=2*J（由于硬件限制，C最大可以取到20），隊列深度為128。下圖是測試結果：

SPDK的性能總是最好的，而性能第二好的API取決于job的數量和CPU核的數量。當J不大于10時，iou+k可以給每個內核線程分配一個CPU，性能最好。此后隨著J的增大，內核線程和應用線程開始搶奪CPU資源，KIOPS開始下滑。在J=12時，iou+k和iou、iou+p的KIOPS交匯，在J=14時，iou+k成為性能最差的API。其他的API隨著job的增長，KIOPS也基本上穩定增長。

iou和iou+p的性能很接近，libaio的帶寬也僅僅比iou、iou+p少10%。

【總結與討論】

1、不同的輪詢方式各有特點

lSPDK的優勢不僅僅體現在用戶態輪詢、無系統調用開銷，還體現在使用單個線程進行輪詢。

liou+k的優勢在CPU不夠時不明顯。

liou+p使用系統級輪詢，在隊列深度較小時可以和SPDK相當。

2、io_uring在特定配置下的性能接近SPDK

3、性能的可擴展性需要仔細考慮

雖然SPDK的性能最好，但需要放棄Linux文件的支持。如果需要使用文件系統，且CPU足夠多，iou+k是不錯的選擇（可以達到90% SPDK的性能），而若CPU資源不足，可以使用iou+p，當隊列深度不深時和SPDK的性能接近。

未來可以在更在實際的I/O密集型應用上測試，如數據庫。它們都需要文件系統的支持，可能會帶來額外的同步開銷，可能會覆蓋I/O路徑上的bottleneck。此外還可以研究更高效的iou+k設計，如不同的應用線程共享一個內核輪詢線程，或者二者更好的使用CPU資源等。最后，io_uring支持socket I/O，所以它的性能也可以測試以評估網絡應用的表現。

審核編輯：湯梓紅