今天分享一篇Linux異步IO編程框架文章，對(duì)比IO復(fù)用的epoll框架，到底性能提高多少？讓我們看一看。

譯者序

• 本文組合翻譯了以下兩篇文章的干貨部分，作為 io_uring 相關(guān)的入門參考：

How io_uring and eBPF Will Revolutionize Programming in Linux[1], ScyllaDB, 2020An Introduction to the io_uring Asynchronous I/O Framework[2], Oracle, 2020

• io_uring 是 2019 年 ?Linux 5.1 內(nèi)核首次引入的高性能異步 I/O 框架，能顯著加速 I/O 密集型應(yīng)用的性能。但如果你的應(yīng)用 已經(jīng)在使用 傳統(tǒng) Linux AIO 了， 并且使用方式恰當(dāng)， 那 io_uring 并不會(huì)帶來(lái)太大的性能提升 —— 根據(jù)原文測(cè)試（以及我們 自己的復(fù)現(xiàn)），即便打開(kāi)高級(jí)特性，也只有 5%。除非你真的需要這 5% 的額外性能，否則切換成 io_uring 代價(jià)可能也挺大，因?yàn)橐貙憫?yīng)用來(lái)適配 io_uring（或者讓依賴的平臺(tái)或框架去適配，總之需要改代碼）。

• 既然性能跟傳統(tǒng) AIO 差不多，那為什么還稱 io_uring 為革命性技術(shù)呢？

• 它首先和最大的貢獻(xiàn)在于：統(tǒng)一了 Linux 異步 I/O 框架，

1. Linux AIO ?只支持 direct I/O 模式的 存儲(chǔ)文件（storage file），而且主要用在 數(shù)據(jù)庫(kù)這一細(xì)分領(lǐng)域；

2. io_uring 支持存儲(chǔ)文件和網(wǎng)絡(luò)文件（network sockets），也支持更多的異步系統(tǒng)調(diào)用 （accept/openat/stat/...），而非僅限于 read/write 系統(tǒng)調(diào)用。

• 在 設(shè)計(jì)上是真正的異步 I/O，作為對(duì)比，Linux AIO 雖然也 是異步的，但仍然可能會(huì)阻塞，某些情況下的行為也無(wú)法預(yù)測(cè)；似乎之前 Windows 在這塊反而是領(lǐng)先的，更多參考：

1. 淺析開(kāi)源項(xiàng)目之 io_uring[3]，“分布式存儲(chǔ)”專欄，知乎

2. Is there really no asynchronous block I/O on Linux?[4]，stackoverflow

• 靈活性和可擴(kuò)展性非常好，甚至能基于 io_uring 重寫所有系統(tǒng)調(diào)用，而 Linux AIO 設(shè)計(jì)時(shí)就沒(méi)考慮擴(kuò)展性。

• eBPF 也算是異步框架（事件驅(qū)動(dòng)），但與 io_uring 沒(méi)有本質(zhì)聯(lián)系，二者屬于不同子系統(tǒng)， 并且在模型上有一個(gè)本質(zhì)區(qū)別：

1. eBPF 對(duì)用戶是透明的，只需升級(jí)內(nèi)核（到合適的版本）， 應(yīng)用程序無(wú)需任何改造；

2. io_uring 提供了 新的系統(tǒng)調(diào)用和用戶空間 API，因此 需要應(yīng)用程序做改造。

• eBPF 作為動(dòng)態(tài)跟蹤工具，能夠更方便地排查和觀測(cè) io_uring 等模塊在執(zhí)行層面的具體問(wèn)題。

• 本文介紹 Linux 異步 I/O 的發(fā)展歷史，io_uring 的原理和功能， 并給出了一些程序示例和性能壓測(cè)結(jié)果（我們?cè)?5.10 內(nèi)核做了類似測(cè)試，結(jié)論與原文差不多）。

• 很多人可能還沒(méi)意識(shí)到，Linux 內(nèi)核在過(guò)去幾年已經(jīng)發(fā)生了一場(chǎng)革命。這場(chǎng)革命源于兩個(gè)激動(dòng)人心的新接口的引入：eBPF 和 io_uring。我們認(rèn)為，二者將會(huì)完全 改變應(yīng)用與內(nèi)核交互的方式，以及應(yīng)用開(kāi)發(fā)者思考和看待內(nèi)核的方式。

• 本文介紹 io_uring（我們?cè)?ScyllaDB 中有 io_uring 的深入使用經(jīng)驗(yàn)），并略微提及一下 eBPF。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【891587639】整理了一些個(gè)人覺(jué)得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。?！前100名進(jìn)群領(lǐng)取，額外贈(zèng)送一份價(jià)值699的內(nèi)核資料包（含視頻教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ? ?

?

1、Linux I/O 系統(tǒng)調(diào)用演進(jìn)

1.1 基于 fd 的阻塞式 I/O：read()/write()

• 作為大家最熟悉的讀寫方式，Linux 內(nèi)核提供了 基于文件描述符的系統(tǒng)調(diào)用， 這些描述符指向的可能是 存儲(chǔ)文件（storage file），也可能是 ?network sockets：

• 二者稱為 阻塞式系統(tǒng)調(diào)用（blocking system calls），因?yàn)槌绦蛘{(diào)用 這些函數(shù)時(shí)會(huì)進(jìn)入 sleep 狀態(tài)，然后被調(diào)度出去（讓出處理器），直到 I/O 操作完成：

1. 如果數(shù)據(jù)在文件中，并且文件內(nèi)容 已經(jīng)緩存在 page cache 中，調(diào)用會(huì) 立即返回；

2. 如果數(shù)據(jù)在另一臺(tái)機(jī)器上，就需要通過(guò)網(wǎng)絡(luò)（例如 TCP）獲取，會(huì)阻塞一段時(shí)間；

3. 如果數(shù)據(jù)在硬盤上，也會(huì)阻塞一段時(shí)間。

• 但很容易想到，隨著存儲(chǔ) 設(shè)備越來(lái)越快，程序越來(lái)越復(fù)雜， 阻塞式（blocking）已經(jīng)這種最簡(jiǎn)單的方式已經(jīng)不適用了。

1.2 非阻塞式 I/O：select()/poll()/epoll()

• 阻塞式之后，出現(xiàn)了一些新的、非阻塞的系統(tǒng)調(diào)用，例如 select()、poll() 以及更新的 epoll()。應(yīng)用程序在調(diào)用這些函數(shù)讀寫時(shí)不會(huì)阻塞，而是 立即返回，返回的是一個(gè)已經(jīng) ready 的文件描述符列表。

• 但這種方式存在一個(gè)致命缺點(diǎn)：只支持 network sockets 和 pipes ——epoll() 甚至連 storage files 都不支持。

1.3 線程池方式

• 對(duì)于 storage I/O，經(jīng)典的解決思路是 thread pool[5]：主線程將 I/O 分發(fā)給 worker 線程，后者代替主線程進(jìn)行阻塞式讀寫，主線程不會(huì)阻塞。

• 這種方式的問(wèn)題是 線程上下文切換開(kāi)銷可能非常大，后面性能壓測(cè)會(huì)看到。

1.4 Direct I/O（數(shù)據(jù)庫(kù)軟件）：繞過(guò) page cache

• 隨后出現(xiàn)了更加靈活和強(qiáng)大的方式：數(shù)據(jù)庫(kù)軟件（database software） 有時(shí) 并不想使用操作系統(tǒng)的 page cache[6]， 而是希望打開(kāi)一個(gè)文件后， 直接從設(shè)備讀寫這個(gè)文件（direct access to the device）。這種方式稱為 直接訪問(wèn)（direct access）或 直接 I/O（direct I/O），

1. 需要指定 ?O_DIRECT flag；

2. 需要 應(yīng)用自己管理自己的緩存 —— 這正是數(shù)據(jù)庫(kù)軟件所希望的；

3. 是 ?zero-copy I/O，因?yàn)閼?yīng)用的緩沖數(shù)據(jù)直接發(fā)送到設(shè)備，或者直接從設(shè)備讀取。

1.5 異步 IO（AIO）

• 前面提到，隨著存儲(chǔ)設(shè)備越來(lái)越快，主線程和 worker 線性之間的上下文切換開(kāi)銷占比越來(lái)越高。現(xiàn)在市場(chǎng)上的一些設(shè)備，例如 Intel Optane[7]， 延遲已經(jīng)低到和上下文切換一個(gè)量級(jí)（微秒 us）。換個(gè)方式描述， 更能讓我們感受到這種開(kāi)銷：上下文每切換一次，我們就少一次 dispatch I/O 的機(jī)會(huì)。

• 因此，Linux ?2.6 內(nèi)核引入了異步 I/O（asynchronous I/O）接口， 方便起見(jiàn)，本文簡(jiǎn)寫為 linux-aio。AIO ?**原理**是很簡(jiǎn)單的：

1. 用戶通過(guò) io_submit() 提交 I/O 請(qǐng)求，

2. 過(guò)一會(huì)再調(diào)用 io_getevents() 來(lái)檢查哪些 events 已經(jīng) ready 了。

3. 使程序員 能編寫完全異步的代碼。

• 近期，Linux AIO 甚至支持了[8] epoll()：也就是說(shuō) 不僅能提交 storage I/O 請(qǐng)求，還能提交網(wǎng)絡(luò) I/O 請(qǐng)求。照這樣發(fā)展下去，linux-aio似乎能成為一個(gè)王者。但由于它糟糕的演進(jìn)之路，這個(gè)愿望幾乎不可能實(shí)現(xiàn)了。我們從 ?Linus 標(biāo)志性的激烈言辭中就能略窺一斑：

Reply to: to support opening files asynchronously[9]So I think this is ridiculously ugly.AIO is a horrible ad-hoc design, with the main excuse being “other, less gifted people, made that design, and we are implementing it for compatibility because database people — who seldom have any shred of taste — actually use it”.— Linus Torvalds (on lwn.net)

• 首先，作為數(shù)據(jù)庫(kù)從業(yè)人員，我們想借此機(jī)會(huì)為我們的沒(méi)品（lack of taste）向 Linus 道歉。但更重要的是，我們要進(jìn)一步解釋一下 為什么 Linus 是對(duì)的：Linux AIO 確實(shí)問(wèn)題纏身，

1. 只支持 O_DIRECT 文件，因此 對(duì)常規(guī)的非數(shù)據(jù)庫(kù)應(yīng)用（normal, non-database Applications） 幾乎是無(wú)用的；

2. 接口在 設(shè)計(jì)時(shí)并未考慮擴(kuò)展性。雖然可以擴(kuò)展 —— 我們也確實(shí)這么做了 —— 但每加一個(gè)東西都相當(dāng)復(fù)雜；

3. 雖然從 技術(shù)上說(shuō)接口是非阻塞的，但實(shí)際上有很多可能的原因都會(huì)導(dǎo)致它阻塞[10]，而且引發(fā)的方式難以預(yù)料。

1.6 小結(jié)

• 以上可以清晰地看出 Linux I/O 的演進(jìn)：

1. 最開(kāi)始是同步（阻塞式）系統(tǒng)調(diào)用；

2. 然后隨著 實(shí)際需求和具體場(chǎng)景，不斷加入新的異步接口，還要保持與老接口的兼容和協(xié)同工作。

• 另外也看到，在非阻塞式讀寫的問(wèn)題上 并沒(méi)有形成統(tǒng)一方案：

1. Network socket 領(lǐng)域：添加一個(gè)異步接口，然后去輪詢（poll）請(qǐng)求是否完成（readiness）；

2. Storage I/O 領(lǐng)域：只針對(duì)某一細(xì)分領(lǐng)域（數(shù)據(jù)庫(kù)）在某一特定時(shí)期的需求，添加了一個(gè)定制版的異步接口。

• 這就是 Linux I/O 的演進(jìn)歷史 —— 只著眼當(dāng)前，出現(xiàn)一個(gè)問(wèn)題就引入一種設(shè)計(jì)，而并沒(méi)有多少前瞻性 —— 直到 io_uring 的出現(xiàn)。

2、io_uring

• io_uring 來(lái)自資深內(nèi)核開(kāi)發(fā)者 Jens Axboe 的想法，他在 Linux I/O stack 領(lǐng)域頗有研究。從最早的 patch aio: support for IO polling[11]可以看出，這項(xiàng)工作始于一個(gè)很簡(jiǎn)單的觀察：隨著設(shè)備越來(lái)越快，中斷驅(qū)動(dòng)（interrupt-driven）模式效率已經(jīng)低于輪詢模式（polling for completions） —— 這也是高性能領(lǐng)域最常見(jiàn)的主題之一。

1. io_uring 的 基本邏輯與 linux-aio 是類似的：提供兩個(gè)接口，一個(gè)將 I/O 請(qǐng)求提交到內(nèi)核，一個(gè)從內(nèi)核接收完成事件。

2. 但隨著開(kāi)發(fā)深入，它逐漸變成了一個(gè)完全不同的接口：設(shè)計(jì)者開(kāi)始從源頭思考如何支持完全異步的操作。

2.1 與 Linux AIO 的不同

• io_uring 與 linux-aio 有著本質(zhì)的不同：

1. 在設(shè)計(jì)上是真正異步的（truly asynchronous）。只要 設(shè)置了合適的 flag，它在 系統(tǒng)調(diào)用上下文中就只是將請(qǐng)求放入隊(duì)列， 不會(huì)做其他任何額外的事情， 保證了應(yīng)用永遠(yuǎn)不會(huì)阻塞。

2. 支持任何類型的 I/O：cached files、direct-access files 甚至 blocking sockets。 由于設(shè)計(jì)上就是異步的（async-by-design nature），因此 無(wú)需 poll+read/write 來(lái)處理 sockets。只需提交一個(gè)阻塞式讀（blocking read），請(qǐng)求完成之后，就會(huì)出現(xiàn)在 completion ring。

3. 靈活、可擴(kuò)展：基于 io_uring 甚至能重寫（re-implement）Linux 的每個(gè)系統(tǒng)調(diào)用。

2.2 原理及核心數(shù)據(jù)結(jié)構(gòu)：SQ/CQ/SQE/CQE

• 每個(gè) io_uring 實(shí)例都有 兩個(gè)環(huán)形隊(duì)列（ring），在內(nèi)核和應(yīng)用程序之間共享：

1. 提交隊(duì)列：submission queue (SQ)

2. 完成隊(duì)列：completion queue (CQ)

• 這兩個(gè)隊(duì)列：

1. 都是 單生產(chǎn)者、單消費(fèi)者，size 是 2 的冪次；

2. 提供 無(wú)鎖接口（lock-less access interface），內(nèi)部使用 **內(nèi)存屏障**做同步（coordinated with memory barriers）。

使用方式：

• 請(qǐng)求

1. 應(yīng)用創(chuàng)建 SQ entries (SQE)，更新 SQ tail；

2. 內(nèi)核消費(fèi) SQE，更新 SQ head。

• 完成

1. 內(nèi)核為完成的一個(gè)或多個(gè)請(qǐng)求創(chuàng)建 CQ entries (CQE)，更新 CQ tail；

2. 應(yīng)用消費(fèi) CQE，更新 CQ head。

3. 完成事件（completion events）可能以任意順序到達(dá)，到總是與特定的 SQE 相關(guān)聯(lián)的。

4. 消費(fèi) CQE 過(guò)程無(wú)需切換到內(nèi)核態(tài)。

2.3 帶來(lái)的好處

1. io_uring 這種請(qǐng)求方式還有一個(gè)好處是：原來(lái)需要多次系統(tǒng)調(diào)用（讀或?qū)懀?，現(xiàn)在變成批處理一次提交。

2. 還記得 Meltdown 漏洞嗎？當(dāng)時(shí)我還寫了一篇文章[12]解釋為什么我們的 Scylla NoSQL 數(shù)據(jù)庫(kù)受影響很小：aio 已經(jīng)將我們的 I/O 系統(tǒng)調(diào)用批處理化了。

3. io_uring 將這種批處理能力帶給了 storage I/O 系統(tǒng)調(diào)用之外的其他一些系統(tǒng)調(diào)用，包括：

readwritesendrecvacceptopenatstat專用的一些系統(tǒng)調(diào)用，例如 fallocate

• 此外，io_uring 使異步 I/O 的使用場(chǎng)景也不再僅限于數(shù)據(jù)庫(kù)應(yīng)用， 普通的 非數(shù)據(jù)庫(kù)應(yīng)用也能用。這一點(diǎn)值得重復(fù)一遍：

雖然 io_uring 與 aio 有一些相似之處，但它的 擴(kuò)展性和架構(gòu)是革命性的：它 將異步操作的強(qiáng)大能力帶給了所有應(yīng)用（及其開(kāi)發(fā)者），而不再僅限于是數(shù)據(jù)庫(kù)應(yīng)用這一細(xì)分領(lǐng)域。

• 我們的 CTO Avi Kivity 在 the Core C++ 2019 event 上 有一次關(guān)于 async 的分享[13]。核心點(diǎn)包括：從延遲上來(lái)說(shuō)，

1. 現(xiàn)代多核、多 CPU 設(shè)備，其內(nèi)部本身就是一個(gè)基礎(chǔ)網(wǎng)絡(luò)；

2. **CPU 之間**是另一個(gè)網(wǎng)絡(luò)；

3. **CPU 和磁盤 I/O 之間**又是一個(gè)網(wǎng)絡(luò)。

• 因此網(wǎng)絡(luò)編程采用異步是明智的，而現(xiàn)在開(kāi)發(fā)自己的應(yīng)用也應(yīng)該考慮異步。這 從根本上改變了 Linux 應(yīng)用的設(shè)計(jì)方式：

1. 之前都是一段順序代碼流，需要系統(tǒng)調(diào)用時(shí)才執(zhí)行系統(tǒng)調(diào)用，

2. 現(xiàn)在需要思考一個(gè)文件是否 ready，因而自然地引入 event-loop，不斷通過(guò)共享 buffer 提交請(qǐng)求和接收結(jié)果。

2.4 三種工作模式

• io_uring 實(shí)例可工作在三種模式：

1. 中斷驅(qū)動(dòng)模式（interrupt driven）

• 默認(rèn)模式。可通過(guò) io_uring_enter() 提交 I/O 請(qǐng)求，然后直接檢查 CQ 狀態(tài)判斷是否完成。

2. 輪詢模式（polled）

• Busy-waiting for an I/O completion，而不是通過(guò)異步 IRQ（Interrupt Request）接收通知。

• 這種模式需要文件系統(tǒng)（如果有）和塊設(shè)備（block device）支持輪詢功能。相比中斷驅(qū)動(dòng)方式，這種方式延遲更低（連系統(tǒng)調(diào)用都省了[14]）， 但可能會(huì)消耗更多 CPU 資源。

• 目前，只有指定了 O_DIRECT flag 打開(kāi)的文件描述符，才能使用這種模式。當(dāng)一個(gè)讀 或?qū)懻?qǐng)求提交給輪詢上下文（polled context）之后，應(yīng)用（Application）必須調(diào)用io_uring_enter() 來(lái)輪詢 CQ 隊(duì)列，判斷請(qǐng)求是否已經(jīng)完成。

• 對(duì)一個(gè) io_uring 實(shí)例來(lái)說(shuō)， 不支持混合使用輪詢和非輪詢模式。

1. 內(nèi)核輪詢模式（kernel polled）

• 這種模式中，會(huì) ?創(chuàng)建一個(gè)內(nèi)核線程（kernel thread）來(lái)執(zhí)行 SQ 的輪詢工作。

• 使用這種模式的 io_uring 實(shí)例， ?應(yīng)用無(wú)需切到到內(nèi)核態(tài) 就能觸發(fā)（issue）I/O 操作。通過(guò) SQ 來(lái)提交 SQE，以及監(jiān)控 CQ 的完成狀態(tài)，應(yīng)用無(wú)需任何系統(tǒng)調(diào)用，就能提交和收割 I/O（submit and reap I/Os）。

• 如果內(nèi)核線程的空閑時(shí)間超過(guò)了用戶的配置值，它會(huì)通知應(yīng)用，然后進(jìn)入 idle 狀態(tài)。這種情況下，應(yīng)用必須調(diào)用 io_uring_enter() 來(lái)喚醒內(nèi)核線程。如果 I/O 一直很繁忙，內(nèi)核線性是不會(huì) sleep 的。

2.5 io_uring 系統(tǒng)調(diào)用 API

• 有三個(gè)：

1. io_uring_setup(2)

2. io_uring_register(2)

3. io_uring_enter(2)

• 下面展開(kāi)介紹。完整文檔見(jiàn) manpage[15]。

2.5.1 io_uring_setup()

• 執(zhí)行異步 I/O 需要先 設(shè)置上下文：

• 這個(gè)系統(tǒng)調(diào)用

• 創(chuàng)建一個(gè) SQ 和一個(gè) CQ，

• queue size 至少 entries 個(gè)元素，

• 返回一個(gè)文件描述符，隨后用于在這個(gè) io_uring 實(shí)例上執(zhí)行操作。

• SQ 和 CQ 在應(yīng)用和內(nèi)核之間共享，避免了在初始化和完成 I/O 時(shí)（initiating and completing I/O）拷貝數(shù)據(jù)。

• 參數(shù) p：

• 應(yīng)用用來(lái)配置 io_uring，

• 內(nèi)核返回的 SQ/CQ 配置信息也通過(guò)它帶回來(lái)。

• io_uring_setup() 成功時(shí)返回一個(gè)文件描述符（fd）。應(yīng)用隨后可以將這個(gè) fd 傳給 mmap(2) 系統(tǒng)調(diào)用，來(lái) map the submission and completion queues 或者傳給 to the io_uring_register() or io_uring_enter() system calls.

• 2.5.2 io_uring_register()

• 注冊(cè)用于異步 I/O 的 文件或用戶緩沖區(qū)（files or user buffers）：

• 注冊(cè)文件或用戶緩沖區(qū)，使內(nèi)核能 長(zhǎng)時(shí)間持有對(duì)該文件在內(nèi)核內(nèi)部的數(shù)據(jù)結(jié)構(gòu)引用（internal kernel data structures associated with the files）， 或創(chuàng)建 應(yīng)用內(nèi)存的長(zhǎng)期映射（long term mAppings of Application memory associated with the buffers）， 這個(gè)操作只會(huì)在注冊(cè)時(shí)執(zhí)行一次，而不是每個(gè) I/O 請(qǐng)求都會(huì)處理，因此減少了 per-I/O overhead。

注冊(cè)的緩沖區(qū)（buffer）性質(zhì)

1. Registered buffers 將會(huì) 被鎖定在內(nèi)存中（be locked in memory），并 計(jì)入用戶的 RLIMIT_MEMLOCK 資源限制。

2. 此外，每個(gè) buffer 有 ?1GB 的大小限制。

3. 當(dāng)前，buffers 必須是 匿名、非文件后端的內(nèi)存（anonymous, non-file-backed memory），例如 malloc(3) or mmap(2) with the MAP_ANONYMOUS flag set 返回的內(nèi)存。

4. Huge pages 也是支持的。整個(gè) huge page 都會(huì)被 pin 到內(nèi)核，即使只用到了其中一部分。

5. 已經(jīng)注冊(cè)的 buffer 無(wú)法調(diào)整大小，想調(diào)整只能先 unregister，再重新 register 一個(gè)新的。

通過(guò) eventfd() 訂閱 completion 事件

• 可以用 eventfd(2) 訂閱 io_uring 實(shí)例的 completion events。將 eventfd 描述符通過(guò)這個(gè)系統(tǒng)調(diào)用注冊(cè)就行了。

The credentials of the running Application can be registered with io_uring which returns an id associated with those credentials. Applications wishing to share a ring between separate users/processes can pass in this credential id in the SQE personality field. If set, that particular SQE will be issued with these credentials.

2.5.3 io_uring_enter()

• 這個(gè)系統(tǒng)調(diào)用用于初始化和完成（initiate and complete）I/O，使用共享的 SQ 和 CQ。單次調(diào)用同時(shí)執(zhí)行：

1. 提交新的 I/O 請(qǐng)求

2. 等待 I/O 完成

• 參數(shù)：

1. fd 是 io_uring_setup() 返回的文件描述符；

2. to_submit 指定了 SQ 中提交的 I/O 數(shù)量；

3. 依據(jù)不同模式：

• 默認(rèn)模式，如果指定了 min_complete，會(huì)等待這個(gè)數(shù)量的 I/O 事件完成再返回；

• 如果 io_uring 是 polling 模式，這個(gè)參數(shù)表示：

1. 0：要求內(nèi)核返回當(dāng)前以及完成的所有 events，無(wú)阻塞；

2. 非零：如果有事件完成，內(nèi)核仍然立即返回；如果沒(méi)有完成事件，內(nèi)核會(huì) poll，等待指定的次數(shù)完成，或者這個(gè)進(jìn)程的時(shí)間片用完。

• 注意：對(duì)于 interrupt driven I/O， 應(yīng)用無(wú)需進(jìn)入內(nèi)核就能檢查 CQ 的 event completions。

• io_uring_enter() 支持很多操作，包括：

Open, close, and stat files Read and write into multiple buffers or pre-mApped buffers Socket I/O operations Synchronize file state Asynchronously monitor a set of file descriptors Create a timeout linked to a specific operation in the ring Attempt to cancel an operation that is currently in flight Create I/O chains Ordered execution within a chain Parallel execution of multiple chains

• 當(dāng)這個(gè)系統(tǒng)調(diào)用返回時(shí)，表示一定數(shù)量的 SEQ 已經(jīng)被消費(fèi)和提交了，此時(shí)可以安全的重用隊(duì)列中的 SEQ。此時(shí) IO 提交有可能還停留在異步上下文中，即實(shí)際上 SQE 可能還沒(méi)有被提交 —— 不過(guò) 用戶不用關(guān)心這些細(xì)節(jié) —— 當(dāng)隨后內(nèi)核需要使用某個(gè)特定的 SQE 時(shí)，它已經(jīng)復(fù)制了一份。

2.6 高級(jí)特性

• io_uring 提供了一些用于特殊場(chǎng)景的高級(jí)特性：

1. File registration（文件注冊(cè)）：每次發(fā)起一個(gè)指定文件描述的操 作，內(nèi)核都需要 花費(fèi)一些時(shí)鐘周期（cycles） 將文件描述符映射到內(nèi)部表示。對(duì)于那些 **針對(duì)同一文件進(jìn)行重復(fù)操作**的場(chǎng)景，io_uring 支持 提前注冊(cè)這些文件，后面直接查找就行了。

2. Buffer registration（緩沖區(qū)注冊(cè)）：與 file registration 類 似，direct I/O 場(chǎng)景中，內(nèi)核需要 map/unmap memory areas。io_uring 支持提前 注冊(cè)這些緩沖區(qū)（buffers）。

3. Poll ring（輪詢環(huán)形緩沖區(qū)）：對(duì)于非?？焓窃O(shè)備，處理中斷的開(kāi) 銷是比較大的。io_uring 允許用戶關(guān)閉中斷，使用輪詢模式。前面“三種工作模式”小節(jié) 也介紹到了這一點(diǎn)。

4. Linked operations（鏈接操作）：允許用戶發(fā)送串聯(lián)的請(qǐng)求。這兩 個(gè)請(qǐng)求同時(shí)提交，但后面的會(huì)等前面的處理完才開(kāi)始執(zhí)行。

2.7 用戶空間庫(kù) liburing

• `liburing`[16] 提供了一個(gè)簡(jiǎn)單的高層 API， 可用于一些基本場(chǎng)景，應(yīng)用程序避免了直接使用更底層的系統(tǒng)調(diào)用。此外，這個(gè) API 還避免了一些重復(fù)操作的代碼，如設(shè)置 io_uring 實(shí)例。

• 舉個(gè)例子，在 io_uring_setup() 的 manpage 描述中，調(diào)用這個(gè)系統(tǒng)調(diào)用獲得一個(gè) ring 文 件描述符之后，應(yīng)用必須調(diào)用 mmap() 來(lái)這樣的邏輯需要一段略長(zhǎng)的代碼，而用liburing 的話，下面的函數(shù)已經(jīng)將上述流程封裝好了：

• 下一節(jié)來(lái)看兩個(gè)例子基于 liburing 的例子。

3 基于 liburing 的示例應(yīng)用

編譯：

3.1 io_uring-test

• 這個(gè)程序使用 4 個(gè) SQE，從輸入文件中 讀取最多 16KB 數(shù)據(jù)。

源碼及注釋

• 為方便看清主要邏輯，忽略了一些錯(cuò)誤處理代碼，完整代碼見(jiàn)io_uring-test.c[17]。

其他說(shuō)明

• 代碼中已經(jīng)添加了注釋，這里再解釋幾點(diǎn)：

1. 每個(gè) SQE 都執(zhí)行一個(gè) allocated buffer，后者是用 iovec 結(jié)構(gòu)描述的；

2. 第 3 & 4 步：初始化所有 SQE，用于接下來(lái)的 IORING_OP_READV 操作，后者提供了 readv(2) 系統(tǒng)調(diào)用的異步接口。

3. 操作完成之后，這個(gè) SQE iovec buffer 中存放的是相關(guān) readv 操作的結(jié)果；

4. 接下來(lái)調(diào)用 io_uring_wait_cqe() 來(lái) reap CQE，并通過(guò) cqe->res 字段驗(yàn)證讀取的字節(jié)數(shù)；

5. io_uring_cqe_seen() 通知內(nèi)核這個(gè) CQE 已經(jīng)被消費(fèi)了。

3.2 link-cp

• link-cp 使用 io_uring 高級(jí)特性 SQE chaining 特性來(lái)復(fù)制文件。

I/O chain

• io_uring 支持創(chuàng)建 I/O chain。一個(gè) chain 內(nèi)的 I/O 是順序執(zhí)行的，多個(gè) I/O chain 可以并行執(zhí)行。

• io_uring_enter() manpage 中對(duì) IOSQE_IO_LINK 有 詳細(xì)解釋[18]：

When this flag is specified, it forms a link with the next SQE in the submission ring. That next SQE will not be started before this one completes. This, in effect, forms a chain of SQEs, which can be arbitrarily long. The tail of the chain is denoted by the first SQE that does not have this flag set. This flag has no effect on previous SQE submissions, nor does it impact SQEs that are outside of the chain tail. This means that multiple chains can be executing in parallel, or chains and individual SQEs. Only members inside the chain are serialized. A chain of SQEs will be broken, if any request in that chain ends in error. io_uring considers any unexpected result an error. This means that, eg, a short read will also terminate the remainder of the chain. If a chain of SQE links is broken, the remaining unstarted part of the chain will be terminated and completed with -ECANCELED as the error code. Available since 5.3.

• 為實(shí)現(xiàn)復(fù)制文件功能，link-cp 創(chuàng)建一個(gè)長(zhǎng)度為 2 的 SQE chain。

1. 第一個(gè) SQE 是一個(gè)讀請(qǐng)求，將數(shù)據(jù)從輸入文件讀到 buffer；

2. 第二個(gè)請(qǐng)求，與第一個(gè)請(qǐng)求是 linked，是一個(gè)寫請(qǐng)求，將數(shù)據(jù)從 buffer 寫入輸出文件。

源碼及注釋

其他說(shuō)明

• 代碼中實(shí)現(xiàn)了三個(gè)函數(shù)：

1. copy_file()：高層復(fù)制循環(huán)邏輯；它會(huì)調(diào)用 queue_rw_pair(ring, this_size, offset) 來(lái)構(gòu)造 SQE pair；并通過(guò)一次 io_uring_submit() 調(diào)用將所有構(gòu)建的 SQE pair 提交。 這個(gè)函數(shù)維護(hù)了一個(gè)最大 DQ 數(shù)量的 inflight SQE，只要數(shù)據(jù) copy 還在進(jìn)行中；否則，即數(shù)據(jù)已經(jīng)全部讀取完成，就開(kāi)始等待和收割所有的 CQE。

2. queue_rw_pair() 構(gòu)造一個(gè) read-write SQE pair. read SQE 的 IOSQE_IO_LINK flag 表示開(kāi)始一個(gè) chain，write SQE 不用設(shè)置這個(gè) flag，標(biāo)志著這個(gè) chain 的結(jié)束。用戶 data 字段設(shè)置為同一個(gè) data 描述符，并且在隨后的 completion 處理中會(huì)用到。

3. handle_cqe() 從 CQE 中提取之前由 ?queue_rw_pair() 保存的 data 描述符，并在描述符中記錄處理進(jìn)展（index）。 如果之前請(qǐng)求被取消，它還會(huì)重新提交 read-write pair。 一個(gè) CQE pair 的兩個(gè) member 都處理完成之后（index==2），釋放共享的 data descriptor。最后通知內(nèi)核這個(gè) CQE 已經(jīng)被消費(fèi)。

4 io_uring 性能壓測(cè)（基于 fio）

1. 對(duì)于已經(jīng)在使用 linux-aio 的應(yīng)用，例如 ScyllaDB，不要期望換成 io_uring 之后能獲得大幅的性能提升，這是因?yàn)椋篿o_uring 性能相關(guān)的底層機(jī)制與 linux-aio 并無(wú)本質(zhì)不同（都是異步提交，輪詢結(jié)果）。

2. 在此，本文也希望使讀者明白：io_uring 首先和最重要的貢獻(xiàn)在于：將 linux-aio 的所有優(yōu)良特性帶給了普羅大眾（而非局限于數(shù)據(jù)庫(kù)這樣的細(xì)分領(lǐng)域）。

4.1 測(cè)試環(huán)境

• 本節(jié)使用 fio 測(cè)試 4 種模式：

1. synchronous reads

2. posix-aio (implemented as a thread pool)

3. linux-aio

4. io_uring

• 硬件：

1. NVMe 存儲(chǔ)設(shè)備，物理極限能打到 ?3.5M IOPS。

2. 8 核處理器

4.2 場(chǎng)景一：direct I/O 1KB 隨機(jī)讀（繞過(guò) page cache）

• 第一組測(cè)試中，我們希望所有的讀請(qǐng)求都能 命中存儲(chǔ)設(shè)備（all reads to hit the storage）， 完全繞開(kāi)操作系統(tǒng)的頁(yè)緩存（page cache）。

• 測(cè)試配置：

1. 8 個(gè) CPU 執(zhí)行 72 fio job，

2. 每個(gè) job 隨機(jī)讀取 4 個(gè)文件，

3. iodepth=8（number of I/O units to keep in flight against the file.）。

• 這種配置 保證了 CPU 處于飽和狀態(tài)，便于觀察 I/O 性能。如果 CPU 數(shù)量足夠多，那每組測(cè)試都可能會(huì)打滿設(shè)備帶寬，結(jié)果對(duì) I/O 壓測(cè)就沒(méi)意義了。

• 表 1. Direct I/O（繞過(guò)系統(tǒng)頁(yè)緩存）：1KB 隨機(jī)讀，CPU 100% 下的 I/O 性能

• 幾點(diǎn)分析：

1. io_uring 相比 linux-aio 確實(shí)有一定提升，但并非革命性的。

2. 開(kāi)啟高級(jí)特性，例如 buffer & file registration 之后性能有進(jìn)一步提升 —— 但也還 沒(méi)有到為了這些性能而重寫整個(gè)應(yīng)用的地步，除非你是搞數(shù)據(jù)庫(kù)研發(fā)，想榨取硬件的最后一分性能。

3. io_uring and linux-aio 都比同步 read 接口快 2 倍，而后者又比 posix-aio 快 2 倍 —— 初看有點(diǎn)差異。但看看 上下文切換次數(shù)，就不難理解為什么 posix-aio 這么慢了。

• 同步 read 性能差是因?yàn)椋涸谶@種沒(méi)有 page cache 的情況下，每次 read 系統(tǒng)調(diào)用都會(huì)阻塞，因此就會(huì)涉及一次上下文切換。

• posix-aio 性能更差是因?yàn)椋翰粌H內(nèi)核和應(yīng)用程序之間要頻繁上下文切換，線程池的 多個(gè)線程之間也在頻繁切換。

4.2 場(chǎng)景二：buffered I/O 1KB 隨機(jī)讀（數(shù)據(jù)提前加載到內(nèi)存，100% hot cache）

• 第二組測(cè)試 buffered I/O：

1. 將文件數(shù)據(jù)提前加載到內(nèi)存，然后再測(cè)隨機(jī)讀。

• 由于 數(shù)據(jù)全部在 page cache，因此 同步 read 永遠(yuǎn)不會(huì)阻塞。

• 這種場(chǎng)景下，我們預(yù)期 同步讀和 io_uring 的性能差距不大（都是最好的）。

• 其他測(cè)試條件不變。

• 表 2. Buffered I/O（數(shù)據(jù)全部來(lái)自 page cache，100% hot cache）：1KB 隨機(jī)讀，100% CPU 下的 I/O 性能

結(jié)果分析：

1. 同步讀和 io_uring 性能差距確實(shí)很小，二者都是最好的。 但注意， **實(shí)際的應(yīng)用**不可能一直 100% 時(shí)間執(zhí)行 IO 操作，因此 基于同步讀的真實(shí)應(yīng)用性能 還是要比基于 io_uring 要差的，因?yàn)?io_uring 會(huì)將多個(gè)系統(tǒng)調(diào)用批處理化。

2. posix-aio 性能最差，直接原因是 上下文切換次數(shù)太多，這也和場(chǎng)景相關(guān)：在這種 ?CPU 飽和的情況下，它的線程池反而是累贅，會(huì)完全拖慢性能。

3. linux-aio 并 不是針對(duì) buffered I/O 設(shè)計(jì)的，在這種 page cache 直接返回的場(chǎng)景， 它的 異步接口反而會(huì)造成性能損失 —— 將操作分 為 dispatch 和 consume 兩步不但沒(méi)有性能收益，反而有額外開(kāi)銷。

4.3 性能測(cè)試小結(jié)

• 最后再次提醒，本節(jié)是極端應(yīng)用/場(chǎng)景（ 100% CPU + 100% cache miss/hit）測(cè)試， 真實(shí)應(yīng)用的行為通常處于同步讀和異步讀之間：時(shí)而一些阻塞操作，時(shí)而一些非阻塞操作。但不管怎么說(shuō)，用了 io_uring 之后，用戶就無(wú)需擔(dān)心同步和異步各占多少比例了，因?yàn)樗?在任何場(chǎng)景下都表現(xiàn)良好。

1. 如果操作是非阻塞的，io_uring 不會(huì)有額外開(kāi)銷；

2. 如果操作是阻塞式的，也沒(méi)關(guān)系，io_uring 是完全異步的，并且不依賴線程池或昂貴的上下文切換來(lái)實(shí)現(xiàn)這種異步能力；

• 本文測(cè)試的都是隨機(jī)讀，但對(duì) 其他類型的操作，io_uring 表現(xiàn)也是非常良好的。例如：

1. 打開(kāi)/關(guān)閉文件

2. 設(shè)置定時(shí)器

3. 通過(guò) network sockets 傳輸數(shù)據(jù)

• 而且 使用的是同一套 io_uring 接口。

4.4 ScyllaDB 與 io_uring

• Scylla 重度依賴 direct I/O，從一開(kāi)始就使用 linux-aio。在我們轉(zhuǎn)向 io_uring 的過(guò)程中，最開(kāi)始測(cè)試顯示對(duì)某些 workloads，能取得 50% 以上的性能提升。但 深入研究之后發(fā)現(xiàn)，這是因?yàn)槲覀?之前的 linux-aio 用的不夠好。這也揭示了一個(gè) 經(jīng)常被忽視的事實(shí)：獲得高性能沒(méi)有那么難（前提是你得弄對(duì)了）。在對(duì)比 io_uring 和 linux-aio 應(yīng)用之后，我們 很快改進(jìn)了一版，二者的性能差距就消失了。但坦率地說(shuō)，解決這個(gè)問(wèn)題 需要一些工作量，因?yàn)橐膭?dòng)一個(gè)已經(jīng)使用 了很多年的基于 linux-aio 的接口。而對(duì) io_uring 應(yīng)用來(lái)說(shuō)，做類似的改動(dòng)是輕而 易舉的。

• 以上只是一個(gè)場(chǎng)景，io_uring 相比 linux-aio 的 **優(yōu)勢(shì)**是能應(yīng)用于 file I/O 之外的場(chǎng)景。此外，它還自帶了特殊的 高性能[19] 接口，例如 buffer registration、file registration、輪詢模式等等。

• 啟用 io_uring 高級(jí)特性之后，我們看到性能確實(shí)有提升：Intel Optane 設(shè)備，單個(gè) CPU ?讀取 512 字節(jié)，觀察到 5% 的性能提升。與 表 1 & 2 對(duì)得上。雖然 5% 的提升 看上去不是太大，但對(duì)于希望壓榨出硬件所有性能的數(shù)據(jù)庫(kù)來(lái)說(shuō)，還是非常寶貴的。

5 eBPF

• eBPF 也是一個(gè) 事件驅(qū)動(dòng)框架（因此也是異步的），允許用戶空間程序動(dòng)態(tài)向內(nèi)核注入字節(jié)碼，主要有兩個(gè)使用場(chǎng)景：

1. Networking：本站[20] 已經(jīng)有相當(dāng)多的文章

2. Tracing & Observability：例如 bcc[21] 等工具

• eBPF 在內(nèi)核 ?4.9 首次引入，4.19 以后功能已經(jīng)很強(qiáng)大。更多關(guān)于 eBPF 的演進(jìn)信息，可參考：（譯）大規(guī)模微服務(wù)利器：eBPF + Kubernetes（KubeCon, 2020）。

• 談到與 io_uring 的結(jié)合，就是用 bcc 之類的工具跟蹤一些 I/O 相關(guān)的內(nèi)核函數(shù)，例如：

1. Trace how much time an Application spends sleeping, and what led to those sleeps. (wakeuptime)

2. Find all programs in the system that reached a particular place in the code (trace)

3. Analyze network TCP throughput aggregated by subnet (tcpsubnet)

4. Measure how much time the kernel spent processing softirqs (softirqs)

5. Capture information about all short-lived files, where they come from, and for how long they were opened (filelife)

6 結(jié)束語(yǔ)

• io_uring 和 eBPF 這兩大特性 將給 Linux 編程帶來(lái)革命性的變化。有了這兩個(gè)特性的加持，開(kāi)發(fā)者就能更充分地利用 Amazon i3en meganode systems[22]之類的多核/多處理器系統(tǒng)，以及 Intel Optane 持久存儲(chǔ)[23]之類的 us 級(jí)延遲存儲(chǔ)設(shè)備。