深入理解Linux异步I/O框架 io_uring
、
來源：云原生實(shí)驗(yàn)室
hi，大家好，今天分享一篇Linux異步IO編程框架文章，對比IO復(fù)用的epoll框架，到底性能提高多少？讓我們看一看。
譯者序
?本文組合翻譯了以下兩篇文章的干貨部分，作為?io_uring?相關(guān)的入門參考：
How io_uring and eBPF Will Revolutionize Programming in Linux[1], ScyllaDB, 2020
An 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 ?并不會帶來太大的性能提升 —— 根據(jù)原文測試（以及我們 自己的復(fù)現(xiàn)），即便打開高級特性，也只有 5%。除非你真的需要這 5% 的額外性能，否則切換成 io_uring ?代價可能也挺大，因?yàn)橐貙憫?yīng)用來適配 io_uring（或者讓依賴的平臺或框架去適配，總之需要改代碼）。
既然性能跟傳統(tǒng) AIO 差不多，那為什么還稱 io_uring 為革命性技術(shù)呢？
它首先和最大的貢獻(xiàn)在于：統(tǒng)一了 Linux 異步 I/O 框架，
Linux AIO ?只支持 direct I/O 模式的 存儲文件（storage file），而且主要用在 數(shù)據(jù)庫這一細(xì)分領(lǐng)域；
io_uring 支持存儲文件和網(wǎng)絡(luò)文件（network sockets），也支持更多的異步系統(tǒng)調(diào)用 （accept/openat/stat/...），而非僅限于 read/write 系統(tǒng)調(diào)用。
在 設(shè)計(jì)上是真正的異步 I/O，作為對比，Linux AIO 雖然也 是異步的，但仍然可能會阻塞，某些情況下的行為也無法預(yù)測；
似乎之前 Windows 在這塊反而是領(lǐng)先的，更多參考：
淺析開源項(xiàng)目之 io_uring[3]，“分布式存儲”專欄，知乎
Is there really no asynchronous block I/O on Linux?[4]，stackoverflow
靈活性和可擴(kuò)展性非常好，甚至能基于 io_uring 重寫所有系統(tǒng)調(diào)用，而 Linux AIO 設(shè)計(jì)時就沒考慮擴(kuò)展性。
eBPF 也算是異步框架（事件驅(qū)動），但與 io_uring 沒有本質(zhì)聯(lián)系，二者屬于不同子系統(tǒng)， 并且在模型上有一個本質(zhì)區(qū)別：
eBPF 對用戶是透明的，只需升級內(nèi)核（到合適的版本）， 應(yīng)用程序無需任何改造；
io_uring 提供了 新的系統(tǒng)調(diào)用和用戶空間 API，因此 需要應(yīng)用程序做改造。
eBPF 作為動態(tài)跟蹤工具，能夠更方便地排查和觀測 io_uring 等模塊在執(zhí)行層面的具體問題。
本文介紹 Linux 異步 I/O 的發(fā)展歷史，io_uring 的原理和功能， 并給出了一些程序示例和性能壓測結(jié)果（我們在 5.10 內(nèi)核做了類似測試，結(jié)論與原文差不多）。
由于譯者水平有限，本文不免存在遺漏或錯誤之處。如有疑問，請查閱原文。
以下是譯文。
很多人可能還沒意識到，Linux 內(nèi)核在過去幾年已經(jīng)發(fā)生了一場革命。這場革命源于兩個激動人心的新接口的引入：eBPF 和 io_uring。我們認(rèn)為，二者將會完全 改變應(yīng)用與內(nèi)核交互的方式，以及應(yīng)用開發(fā)者思考和看待內(nèi)核的方式。
本文介紹 io_uring（我們在 ScyllaDB 中有 io_uring 的深入使用經(jīng)驗(yàn)），并略微提及一下 eBPF。
1 Linux I/O 系統(tǒng)調(diào)用演進(jìn)
1.1 基于 fd 的阻塞式 I/O：read()/write()
作為大家最熟悉的讀寫方式，Linux 內(nèi)核提供了 基于文件描述符的系統(tǒng)調(diào)用， 這些描述符指向的可能是 存儲文件（storage file），也可能是 ?network sockets：
ssize_t?read(int?fd,?void?*buf,?size_t?count); ssize_t?write(int?fd,?const?void?*buf,?size_t?count);二者稱為 阻塞式系統(tǒng)調(diào)用（blocking system calls），因?yàn)槌绦蛘{(diào)用 這些函數(shù)時會進(jìn)入 sleep 狀態(tài)，然后被調(diào)度出去（讓出處理器），直到 I/O 操作完成：
如果數(shù)據(jù)在文件中，并且文件內(nèi)容 已經(jīng)緩存在 page cache 中，調(diào)用會 立即返回；
如果數(shù)據(jù)在另一臺機(jī)器上，就需要通過網(wǎng)絡(luò)（例如 TCP）獲取，會阻塞一段時間；
如果數(shù)據(jù)在硬盤上，也會阻塞一段時間。
但很容易想到，隨著存儲 設(shè)備越來越快，程序越來越復(fù)雜， 阻塞式（blocking）已經(jīng)這種最簡單的方式已經(jīng)不適用了。
1.2 非阻塞式 I/O：select()/poll()/epoll()
阻塞式之后，出現(xiàn)了一些新的、非阻塞的系統(tǒng)調(diào)用，例如 select()、poll() 以及更新的 epoll()。應(yīng)用程序在調(diào)用這些函數(shù)讀寫時不會阻塞，而是 立即返回，返回的是一個已經(jīng) ready 的文件描述符列表。
但這種方式存在一個致命缺點(diǎn)：只支持 network sockets 和 pipes ——epoll() 甚至連 storage files 都不支持。
1.3 線程池方式
對于 storage I/O，經(jīng)典的解決思路是 thread pool[5]：主線程將 I/O 分發(fā)給 worker 線程，后者代替主線程進(jìn)行阻塞式讀寫，主線程不會阻塞。
這種方式的問題是 線程上下文切換開銷可能非常大，后面性能壓測會看到。
1.4 Direct I/O（數(shù)據(jù)庫軟件）：繞過 page cache
隨后出現(xiàn)了更加靈活和強(qiáng)大的方式：數(shù)據(jù)庫軟件（database software） 有時 并不想使用操作系統(tǒng)的 page cache[6]， 而是希望打開一個文件后， 直接從設(shè)備讀寫這個文件（direct access to the device）。這種方式稱為 直接訪問（direct access）或 直接 I/O（direct I/O），
需要指定 ?O_DIRECT flag；
需要 應(yīng)用自己管理自己的緩存 —— 這正是數(shù)據(jù)庫軟件所希望的；
是 ?zero-copy I/O，因?yàn)閼?yīng)用的緩沖數(shù)據(jù)直接發(fā)送到設(shè)備，或者直接從設(shè)備讀取。
1.5 異步 IO（AIO）
前面提到，隨著存儲設(shè)備越來越快，主線程和 worker 線性之間的上下文切換開銷占比越來越高。現(xiàn)在市場上的一些設(shè)備，例如 Intel Optane[7]， 延遲已經(jīng)低到和上下文切換一個量級（微秒 us）。換個方式描述， 更能讓我們感受到這種開銷：上下文每切換一次，我們就少一次 dispatch I/O 的機(jī)會。
因此，Linux ?2.6 內(nèi)核引入了異步 I/O（asynchronous I/O）接口， 方便起見，本文簡寫為 linux-aio。AIO ?**原理**是很簡單的：
用戶通過 io_submit() 提交 I/O 請求，
過一會再調(diào)用 io_getevents() 來檢查哪些 events 已經(jīng) ready 了。
使程序員 能編寫完全異步的代碼。
近期，Linux AIO 甚至支持了[8]epoll()：也就是說 不僅能提交 storage I/O 請求，還能提交網(wǎng)絡(luò) I/O 請求。照這樣發(fā)展下去，linux-aio似乎能成為一個王者。但由于它糟糕的演進(jìn)之路，這個愿望幾乎不可能實(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ù)庫從業(yè)人員，我們想借此機(jī)會為我們的沒品（lack of taste）向 Linus 道歉。但更重要的是，我們要進(jìn)一步解釋一下 為什么 Linus 是對的：Linux AIO 確實(shí)問題纏身，
只支持 O_DIRECT 文件，因此 對常規(guī)的非數(shù)據(jù)庫應(yīng)用（normal, non-database applications） 幾乎是無用的；
接口在 設(shè)計(jì)時并未考慮擴(kuò)展性。雖然可以擴(kuò)展 —— 我們也確實(shí)這么做了 —— 但每加一個東西都相當(dāng)復(fù)雜；
雖然從 技術(shù)上說接口是非阻塞的，但實(shí)際上有很多可能的原因都會導(dǎo)致它阻塞[10]，而且引發(fā)的方式難以預(yù)料。
1.6 小結(jié)
以上可以清晰地看出 Linux I/O 的演進(jìn)：
最開始是同步（阻塞式）系統(tǒng)調(diào)用；
然后隨著 實(shí)際需求和具體場景，不斷加入新的異步接口，還要保持與老接口的兼容和協(xié)同工作。
另外也看到，在非阻塞式讀寫的問題上 并沒有形成統(tǒng)一方案：
Network socket 領(lǐng)域：添加一個異步接口，然后去輪詢（poll）請求是否完成（readiness）；
Storage I/O 領(lǐng)域：只針對某一細(xì)分領(lǐng)域（數(shù)據(jù)庫）在某一特定時期的需求，添加了一個定制版的異步接口。
這就是 Linux I/O 的演進(jìn)歷史 —— 只著眼當(dāng)前，出現(xiàn)一個問題就引入一種設(shè)計(jì)，而并沒有多少前瞻性 —— 直到 io_uring 的出現(xiàn)。
2 io_uring
io_uring 來自資深內(nèi)核開發(fā)者 Jens Axboe 的想法，他在 Linux I/O stack 領(lǐng)域頗有研究。從最早的 patch aio: support for IO polling[11]可以看出，這項(xiàng)工作始于一個很簡單的觀察：隨著設(shè)備越來越快，中斷驅(qū)動（interrupt-driven）模式效率已經(jīng)低于輪詢模式（polling for completions） —— 這也是高性能領(lǐng)域最常見的主題之一。
io_uring 的 基本邏輯與 linux-aio 是類似的：提供兩個接口，一個將 I/O 請求提交到內(nèi)核，一個從內(nèi)核接收完成事件。
但隨著開發(fā)深入，它逐漸變成了一個完全不同的接口：設(shè)計(jì)者開始從源頭思考如何支持完全異步的操作。
2.1 與 Linux AIO 的不同
io_uring 與 linux-aio 有著本質(zhì)的不同：
在設(shè)計(jì)上是真正異步的（truly asynchronous）。只要 設(shè)置了合適的 flag，它在 系統(tǒng)調(diào)用上下文中就只是將請求放入隊(duì)列， 不會做其他任何額外的事情， 保證了應(yīng)用永遠(yuǎn)不會阻塞。
支持任何類型的 I/O：cached files、direct-access files 甚至 blocking sockets。
由于設(shè)計(jì)上就是異步的（async-by-design nature），因此 無需 poll+read/write 來處理 sockets。只需提交一個阻塞式讀（blocking read），請求完成之后，就會出現(xiàn)在 completion ring。
靈活、可擴(kuò)展：基于 io_uring 甚至能重寫（re-implement）Linux 的每個系統(tǒng)調(diào)用。
2.2 原理及核心數(shù)據(jù)結(jié)構(gòu)：SQ/CQ/SQE/CQE
每個 io_uring 實(shí)例都有 兩個環(huán)形隊(duì)列（ring），在內(nèi)核和應(yīng)用程序之間共享：
提交隊(duì)列：submission queue (SQ)
完成隊(duì)列：completion queue (CQ)
這兩個隊(duì)列：
都是 單生產(chǎn)者、單消費(fèi)者，size 是 2 的冪次；
提供 無鎖接口（lock-less access interface），內(nèi)部使用 **內(nèi)存屏障**做同步（coordinated with memory barriers）。
使用方式：
請求
應(yīng)用創(chuàng)建 SQ entries (SQE)，更新 SQ tail；
內(nèi)核消費(fèi) SQE，更新 SQ head。
完成
內(nèi)核為完成的一個或多個請求創(chuàng)建 CQ entries (CQE)，更新 CQ tail；
應(yīng)用消費(fèi) CQE，更新 CQ head。
完成事件（completion events）可能以任意順序到達(dá)，到總是與特定的 SQE 相關(guān)聯(lián)的。
消費(fèi) CQE 過程無需切換到內(nèi)核態(tài)。
2.3 帶來的好處
io_uring 這種請求方式還有一個好處是：原來需要多次系統(tǒng)調(diào)用（讀或?qū)?#xff09;，現(xiàn)在變成批處理一次提交。
還記得 Meltdown 漏洞嗎？當(dāng)時我還寫了一篇文章[12]解釋為什么我們的 Scylla NoSQL 數(shù)據(jù)庫受影響很小：aio 已經(jīng)將我們的 I/O 系統(tǒng)調(diào)用批處理化了。
io_uring ?將這種批處理能力帶給了 storage I/O 系統(tǒng)調(diào)用之外的其他一些系統(tǒng)調(diào)用，包括：
read
write
send
recv
accept
openat
stat
專用的一些系統(tǒng)調(diào)用，例如 fallocate
此外，io_uring 使異步 I/O 的使用場景也不再僅限于數(shù)據(jù)庫應(yīng)用， 普通的 非數(shù)據(jù)庫應(yīng)用也能用。這一點(diǎn)值得重復(fù)一遍：
雖然 io_uring 與 aio 有一些相似之處，但它的 擴(kuò)展性和架構(gòu)是革命性的：它 將異步操作的強(qiáng)大能力帶給了所有應(yīng)用（及其開發(fā)者），而不再僅限于是數(shù)據(jù)庫應(yīng)用這一細(xì)分領(lǐng)域。
我們的 CTO Avi Kivity 在 the Core C++ 2019 event 上 有一次關(guān)于 async 的分享[13]。核心點(diǎn)包括：從延遲上來說，
現(xiàn)代多核、多 CPU 設(shè)備，其內(nèi)部本身就是一個基礎(chǔ)網(wǎng)絡(luò)；
**CPU 之間**是另一個網(wǎng)絡(luò)；
**CPU 和磁盤 I/O 之間**又是一個網(wǎng)絡(luò)。
因此網(wǎng)絡(luò)編程采用異步是明智的，而現(xiàn)在開發(fā)自己的應(yīng)用也應(yīng)該考慮異步。這 從根本上改變了 Linux 應(yīng)用的設(shè)計(jì)方式：
之前都是一段順序代碼流，需要系統(tǒng)調(diào)用時才執(zhí)行系統(tǒng)調(diào)用，
現(xiàn)在需要思考一個文件是否 ready，因而自然地引入 event-loop，不斷通過共享 buffer 提交請求和接收結(jié)果。
2.4 三種工作模式
io_uring 實(shí)例可工作在三種模式：
中斷驅(qū)動模式（interrupt driven）
默認(rèn)模式。可通過 io_uring_enter() 提交 I/O 請求，然后直接檢查 CQ 狀態(tài)判斷是否完成。
輪詢模式（polled）
Busy-waiting for an I/O completion，而不是通過異步 IRQ（Interrupt Request）接收通知。
這種模式需要文件系統(tǒng)（如果有）和塊設(shè)備（block device）支持輪詢功能。相比中斷驅(qū)動方式，這種方式延遲更低（連系統(tǒng)調(diào)用都省了[14]）， 但可能會消耗更多 CPU 資源。
目前，只有指定了 O_DIRECT flag 打開的文件描述符，才能使用這種模式。當(dāng)一個讀 或?qū)懻埱筇峤唤o輪詢上下文（polled context）之后，應(yīng)用（application）必須調(diào)用io_uring_enter() 來輪詢 CQ 隊(duì)列，判斷請求是否已經(jīng)完成。
對一個 io_uring 實(shí)例來說， 不支持混合使用輪詢和非輪詢模式。
內(nèi)核輪詢模式（kernel polled）
這種模式中，會 ?創(chuàng)建一個內(nèi)核線程（kernel thread）來執(zhí)行 SQ 的輪詢工作。
使用這種模式的 io_uring 實(shí)例， ?應(yīng)用無需切到到內(nèi)核態(tài) 就能觸發(fā)（issue）I/O 操作。通過 SQ 來提交 SQE，以及監(jiān)控 CQ 的完成狀態(tài)，應(yīng)用無需任何系統(tǒng)調(diào)用，就能提交和收割 I/O（submit and reap I/Os）。
如果內(nèi)核線程的空閑時間超過了用戶的配置值，它會通知應(yīng)用，然后進(jìn)入 idle 狀態(tài)。這種情況下，應(yīng)用必須調(diào)用 io_uring_enter() 來喚醒內(nèi)核線程。如果 I/O 一直很繁忙，內(nèi)核線性是不會 sleep 的。
2.5 io_uring 系統(tǒng)調(diào)用 API
有三個：
io_uring_setup(2)
io_uring_register(2)
io_uring_enter(2)
下面展開介紹。完整文檔見 manpage[15]。
2.5.1 io_uring_setup()
執(zhí)行異步 I/O 需要先 設(shè)置上下文：
int?io_uring_setup(u32?entries,?struct?io_uring_params?*p);這個系統(tǒng)調(diào)用
創(chuàng)建一個 SQ 和一個 CQ，
queue size 至少 entries 個元素，
返回一個文件描述符，隨后用于在這個 io_uring 實(shí)例上執(zhí)行操作。
SQ 和 CQ 在應(yīng)用和內(nèi)核之間共享，避免了在初始化和完成 I/O 時（initiating and completing I/O）拷貝數(shù)據(jù)。
參數(shù) p：
應(yīng)用用來配置 io_uring，
內(nèi)核返回的 SQ/CQ 配置信息也通過它帶回來。
io_uring_setup() 成功時返回一個文件描述符（fd）。應(yīng)用隨后可以將這個 fd 傳給 mmap(2) 系統(tǒng)調(diào)用，來 map the submission and completion queues 或者傳給 to the io_uring_register() or io_uring_enter() system calls.
2.5.2 io_uring_register()
注冊用于異步 I/O 的 文件或用戶緩沖區(qū)（files or user buffers）：
int?io_uring_register(unsigned?int?fd,?unsigned?int?opcode,?void?*arg,?unsigned?int?nr_args);注冊文件或用戶緩沖區(qū)，使內(nèi)核能 長時間持有對該文件在內(nèi)核內(nèi)部的數(shù)據(jù)結(jié)構(gòu)引用（internal kernel data structures associated with the files）， 或創(chuàng)建 應(yīng)用內(nèi)存的長期映射（long term mappings of application memory associated with the buffers）， 這個操作只會在注冊時執(zhí)行一次，而不是每個 I/O 請求都會處理，因此減少了 per-I/O overhead。
注冊的緩沖區(qū)（buffer）性質(zhì)
Registered buffers 將會 被鎖定在內(nèi)存中（be locked in memory），并 計(jì)入用戶的 RLIMIT_MEMLOCK 資源限制。
此外，每個 buffer 有 ?1GB 的大小限制。
當(dāng)前，buffers 必須是 匿名、非文件后端的內(nèi)存（anonymous, non-file-backed memory），例如 malloc(3) or mmap(2) with the MAP_ANONYMOUS flag set 返回的內(nèi)存。
Huge pages 也是支持的。整個 huge page 都會被 pin 到內(nèi)核，即使只用到了其中一部分。
已經(jīng)注冊的 buffer 無法調(diào)整大小，想調(diào)整只能先 unregister，再重新 register 一個新的。
通過 eventfd() 訂閱 completion 事件
可以用 eventfd(2) 訂閱 io_uring 實(shí)例的 completion events。將 eventfd 描述符通過這個系統(tǒng)調(diào)用注冊就行了。
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()
int?io_uring_enter(unsigned?int?fd,?unsigned?int?to_submit,?unsigned?int?min_complete,?unsigned?int?flags,?sigset_t?*sig);這個系統(tǒng)調(diào)用用于初始化和完成（initiate and complete）I/O，使用共享的 SQ 和 CQ。單次調(diào)用同時執(zhí)行：
提交新的 I/O 請求
等待 I/O 完成
參數(shù)：
fd 是 io_uring_setup() 返回的文件描述符；
to_submit 指定了 SQ 中提交的 I/O 數(shù)量；
依據(jù)不同模式：
默認(rèn)模式，如果指定了 min_complete，會等待這個數(shù)量的 I/O 事件完成再返回；
如果 io_uring 是 polling 模式，這個參數(shù)表示：
0：要求內(nèi)核返回當(dāng)前以及完成的所有 events，無阻塞；
非零：如果有事件完成，內(nèi)核仍然立即返回；如果沒有完成事件，內(nèi)核會 poll，等待指定的次數(shù)完成，或者這個進(jìn)程的時間片用完。
注意：對于 interrupt driven I/O， 應(yīng)用無需進(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)這個系統(tǒng)調(diào)用返回時，表示一定數(shù)量的 SEQ 已經(jīng)被消費(fèi)和提交了，此時可以安全的重用隊(duì)列中的 SEQ。此時 IO 提交有可能還停留在異步上下文中，即實(shí)際上 SQE 可能還沒有被提交 —— 不過 用戶不用關(guān)心這些細(xì)節(jié) —— 當(dāng)隨后內(nèi)核需要使用某個特定的 SQE 時，它已經(jīng)復(fù)制了一份。
2.6 高級特性
io_uring 提供了一些用于特殊場景的高級特性：
File registration（文件注冊）：每次發(fā)起一個指定文件描述的操 作，內(nèi)核都需要 花費(fèi)一些時鐘周期（cycles） 將文件描述符映射到內(nèi)部表示。對于那些 **針對同一文件進(jìn)行重復(fù)操作**的場景，io_uring 支持 提前注冊這些文件，后面直接查找就行了。
Buffer registration（緩沖區(qū)注冊）：與 file registration 類 似，direct I/O 場景中，內(nèi)核需要 map/unmap memory areas。io_uring 支持提前 注冊這些緩沖區(qū)（buffers）。
Poll ring（輪詢環(huán)形緩沖區(qū)）：對于非常快是設(shè)備，處理中斷的開 銷是比較大的。io_uring 允許用戶關(guān)閉中斷，使用輪詢模式。前面“三種工作模式”小節(jié) 也介紹到了這一點(diǎn)。
Linked operations（鏈接操作）：允許用戶發(fā)送串聯(lián)的請求。這兩 個請求同時提交，但后面的會等前面的處理完才開始執(zhí)行。
2.7 用戶空間庫 liburing
`liburing`[16] 提供了一個簡單的高層 API， 可用于一些基本場景，應(yīng)用程序避免了直接使用更底層的系統(tǒng)調(diào)用。此外，這個 API 還避免了一些重復(fù)操作的代碼，如設(shè)置 io_uring 實(shí)例。
舉個例子，在 io_uring_setup() 的 manpage 描述中，調(diào)用這個系統(tǒng)調(diào)用獲得一個 ring 文 件描述符之后，應(yīng)用必須調(diào)用 mmap() 來這樣的邏輯需要一段略長的代碼，而用liburing 的話，下面的函數(shù)已經(jīng)將上述流程封裝好了：
int?io_uring_queue_init(unsigned?entries,?struct?io_uring?*ring,?unsigned?flags);下一節(jié)來看兩個例子基于 liburing 的例子。
3 基于 liburing 的示例應(yīng)用
編譯：
$?git?clone?https://github.com/axboe/liburing.git $?git?co?-b?liburing-2.0?tags/liburing-2.0$?cd?liburing $?ls?examples/ io_uring-cp??io_uring-cp.c??io_uring-test??io_uring-test.c??link-cp??link-cp.c??Makefile??ucontext-cp??ucontext-cp.c$?make?-j4$?./examples/io_uring-test?<file> Submitted=4,?completed=4,?bytes=16384$?./examples/link-cp?<in-file>?<out-file>3.1 io_uring-test
這個程序使用 4 個 SQE，從輸入文件中 讀取最多 16KB 數(shù)據(jù)。
源碼及注釋
為方便看清主要邏輯，忽略了一些錯誤處理代碼，完整代碼見io_uring-test.c[17]。
/*?SPDX-License-Identifier:?MIT?*/ /**?Simple?app?that?demonstrates?how?to?setup?an?io_uring?interface,*?submit?and?complete?IO?against?it,?and?then?tear?it?down.**?gcc?-Wall?-O2?-D_GNU_SOURCE?-o?io_uring-test?io_uring-test.c?-luring*/ #include?"liburing.h"#define?QD????4?//?io_uring?隊(duì)列長度int?main(int?argc,?char?*argv[])?{int?i,?fd,?pending,?done;void?*buf;//?1.?初始化一個?io_uring?實(shí)例struct?io_uring?ring;ret?=?io_uring_queue_init(QD,????//?隊(duì)列長度&ring,?//?io_uring?實(shí)例0);????//?flags，0?表示默認(rèn)配置，例如使用中斷驅(qū)動模式//?2.?打開輸入文件，注意這里指定了?O_DIRECT?flag，內(nèi)核輪詢模式需要這個?flag，見前面介紹fd?=?open(argv[1],?O_RDONLY?|?O_DIRECT);struct?stat?sb;fstat(fd,?&sb);?//?獲取文件信息，例如文件長度，后面會用到//?3.?初始化?4?個讀緩沖區(qū)ssize_t?fsize?=?0;?????????????//?程序的最大讀取長度struct?iovec?*iovecs?=?calloc(QD,?sizeof(struct?iovec));for?(i?=?0;?i?<?QD;?i++)?{if?(posix_memalign(&buf,?4096,?4096))return?1;iovecs[i].iov_base?=?buf;??//?起始地址iovecs[i].iov_len?=?4096;??//?緩沖區(qū)大小fsize?+=?4096;}//?4.?依次準(zhǔn)備?4?個?SQE?讀請求，指定將隨后讀入的數(shù)據(jù)寫入?iovecs?struct?io_uring_sqe?*sqe;offset?=?0;i?=?0;do?{sqe?=?io_uring_get_sqe(&ring);??//?獲取可用?SQEio_uring_prep_readv(sqe,????????//?用這個?SQE?準(zhǔn)備一個待提交的?read?操作fd,?????????//?從?fd?打開的文件中讀取數(shù)據(jù)&iovecs[i],?//?iovec?地址，讀到的數(shù)據(jù)寫入?iovec?緩沖區(qū)1,??????????//?iovec?數(shù)量offset);????//?讀取操作的起始地址偏移量offset?+=?iovecs[i].iov_len;????//?更新偏移量，下次使用i++;if?(offset?>?sb.st_size)????????//?如果超出了文件大小，停止準(zhǔn)備后面的?SQEbreak;}?while?(1);//?5.?提交?SQE?讀請求ret?=?io_uring_submit(&ring);???????//?4?個?SQE?一次提交，返回提交成功的?SQE?數(shù)量if?(ret?<?0)?{fprintf(stderr,?"io_uring_submit:?%s\n",?strerror(-ret));return?1;}?else?if?(ret?!=?i)?{fprintf(stderr,?"io_uring_submit?submitted?less?%d\n",?ret);return?1;}//?6.?等待讀請求完成（CQE）struct?io_uring_cqe?*cqe;done?=?0;pending?=?ret;fsize?=?0;for?(i?=?0;?i?<?pending;?i++)?{io_uring_wait_cqe(&ring,?&cqe);??//?等待系統(tǒng)返回一個讀完成事件done++;if?(cqe->res?!=?4096?&&?cqe->res?+?fsize?!=?sb.st_size)?{fprintf(stderr,?"ret=%d,?wanted?4096\n",?cqe->res);}fsize?+=?cqe->res;io_uring_cqe_seen(&ring,?cqe);???//?更新?io_uring?實(shí)例的完成隊(duì)列}//?7.?打印統(tǒng)計(jì)信息printf("Submitted=%d,?completed=%d,?bytes=%lu\n",?pending,?done,?(unsigned?long)?fsize);//?8.?清理工作close(fd);io_uring_queue_exit(&ring);return?0; }其他說明
代碼中已經(jīng)添加了注釋，這里再解釋幾點(diǎn)：
每個 SQE 都執(zhí)行一個 allocated buffer，后者是用 iovec 結(jié)構(gòu)描述的；
第 3 & 4 步：初始化所有 SQE，用于接下來的 IORING_OP_READV 操作，后者提供了 readv(2) 系統(tǒng)調(diào)用的異步接口。
操作完成之后，這個 SQE iovec buffer 中存放的是相關(guān) readv 操作的結(jié)果；
接下來調(diào)用 io_uring_wait_cqe() 來 reap CQE，并通過 cqe->res 字段驗(yàn)證讀取的字節(jié)數(shù)；
io_uring_cqe_seen() 通知內(nèi)核這個 CQE 已經(jīng)被消費(fèi)了。
3.2 link-cp
link-cp 使用 io_uring 高級特性 SQE chaining 特性來復(fù)制文件。
I/O chain
io_uring 支持創(chuàng)建 I/O chain。一個 chain 內(nèi)的 I/O 是順序執(zhí)行的，多個 I/O chain 可以并行執(zhí)行。
io_uring_enter() manpage 中對 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)建一個長度為 2 的 SQE chain。
第一個 SQE 是一個讀請求，將數(shù)據(jù)從輸入文件讀到 buffer；
第二個請求，與第一個請求是 linked，是一個寫請求，將數(shù)據(jù)從 buffer 寫入輸出文件。
源碼及注釋
/*?SPDX-License-Identifier:?MIT?*/ /**?Very?basic?proof-of-concept?for?doing?a?copy?with?linked?SQEs.?Needs?a*?bit?of?error?handling?and?short?read?love.*/ #include?"liburing.h"#define?QD????64?????????//?io_uring?隊(duì)列長度 #define?BS????(32*1024)struct?io_data?{size_t?offset;int?index;struct?iovec?iov; };static?int?infd,?outfd; static?unsigned?inflight;//?創(chuàng)建一個?read->write?SQE?chain static?void?queue_rw_pair(struct?io_uring?*ring,?off_t?size,?off_t?offset)?{struct?io_uring_sqe?*sqe;struct?io_data?*data;void?*ptr;ptr?=?malloc(size?+?sizeof(*data));data?=?ptr?+?size;data->index?=?0;data->offset?=?offset;data->iov.iov_base?=?ptr;data->iov.iov_len?=?size;sqe?=?io_uring_get_sqe(ring);????????????????????????????//?獲取可用?SQEio_uring_prep_readv(sqe,?infd,?&data->iov,?1,?offset);???//?準(zhǔn)備?read?請求sqe->flags?|=?IOSQE_IO_LINK;?????????????????????????????//?設(shè)置為?LINK?模式io_uring_sqe_set_data(sqe,?data);????????????????????????//?設(shè)置?datasqe?=?io_uring_get_sqe(ring);????????????????????????????//?獲取另一個可用?SQEio_uring_prep_writev(sqe,?outfd,?&data->iov,?1,?offset);?//?準(zhǔn)備?write?請求io_uring_sqe_set_data(sqe,?data);????????????????????????//?設(shè)置?data }//?處理完成（completion）事件：釋放 SQE 的內(nèi)存緩沖區(qū)，通知內(nèi)核已經(jīng)消費(fèi)了 CQE。 static?int?handle_cqe(struct?io_uring?*ring,?struct?io_uring_cqe?*cqe)?{struct?io_data?*data?=?io_uring_cqe_get_data(cqe);???????//?獲取?CQEdata->index++;if?(cqe->res?<?0)?{if?(cqe->res?==?-ECANCELED)?{queue_rw_pair(ring,?BS,?data->offset);inflight?+=?2;}?else?{printf("cqe?error:?%s\n",?strerror(cqe->res));ret?=?1;}}if?(data->index?==?2)?{????????//?read->write?chain?完成，釋放緩沖區(qū)內(nèi)存void?*ptr?=?(void?*)?data?-?data->iov.iov_len;free(ptr);}io_uring_cqe_seen(ring,?cqe);??//?通知內(nèi)核已經(jīng)消費(fèi)了?CQE?事件return?ret; }static?int?copy_file(struct?io_uring?*ring,?off_t?insize)?{struct?io_uring_cqe?*cqe;size_t?this_size;off_t?offset;offset?=?0;while?(insize)?{??????????????????????//?數(shù)據(jù)還沒處理完int?has_inflight?=?inflight;??????//?當(dāng)前正在進(jìn)行中的?SQE?數(shù)量int?depth;??//?SQE?閾值，當(dāng)前進(jìn)行中的?SQE?數(shù)量（inflight）超過這個值之后，需要阻塞等待?CQE?完成while?(insize?&&?inflight?<?QD)?{?//?數(shù)據(jù)還沒處理完，io_uring?隊(duì)列也還沒用完this_size?=?BS;if?(this_size?>?insize)???????//?最后一段數(shù)據(jù)不足?BS?大小this_size?=?insize;queue_rw_pair(ring,?this_size,?offset);?//?創(chuàng)建一個?read->write?chain，占用兩個?SQEoffset?+=?this_size;insize?-=?this_size;inflight?+=?2;????????????????//?正在進(jìn)行中的?SQE?數(shù)量?+2}if?(has_inflight?!=?inflight)?????//?如果有新創(chuàng)建的?SQE，io_uring_submit(ring);????????//?就提交給內(nèi)核if?(insize)???????????????????????//?如果還有?data?等待處理，depth?=?QD;???????????????????//?閾值設(shè)置 SQ 的隊(duì)列長度，即 SQ 隊(duì)列用完才開始阻塞等待 CQE；else??????????????????????????????//?data?處理已經(jīng)全部提交，depth?=?1;????????????????????//?閾值設(shè)置為?1，即只要還有?SQE?未完成，就阻塞等待?CQE//?下面這個?while?只有?SQ?隊(duì)列用完或?data?全部提交之后才會執(zhí)行到while?(inflight?>=?depth)?{???????//?如果所有?SQE?都已經(jīng)用完，或者所有?data?read->write?請求都已經(jīng)提交io_uring_wait_cqe(ring,?&cqe);//?等待內(nèi)核?completion?事件handle_cqe(ring,?cqe);????????//?處理 completion 事件：釋放 SQE 內(nèi)存緩沖區(qū)，通知內(nèi)核 CQE 已消費(fèi)inflight--;???????????????????//?正在進(jìn)行中的?SQE?數(shù)量?-1}}return?0; }static?int?setup_context(unsigned?entries,?struct?io_uring?*ring)?{io_uring_queue_init(entries,?ring,?0);return?0; }static?int?get_file_size(int?fd,?off_t?*size)?{struct?stat?st;if?(fstat(fd,?&st)?<?0)return?-1;if?(S_ISREG(st.st_mode))?{*size?=?st.st_size;return?0;}?else?if?(S_ISBLK(st.st_mode))?{unsigned?long?long?bytes;if?(ioctl(fd,?BLKGETSIZE64,?&bytes)?!=?0)return?-1;*size?=?bytes;return?0;}return?-1; }int?main(int?argc,?char?*argv[])?{struct?io_uring?ring;off_t?insize;int?ret;infd?=?open(argv[1],?O_RDONLY);outfd?=?open(argv[2],?O_WRONLY?|?O_CREAT?|?O_TRUNC,?0644);if?(setup_context(QD,?&ring))return?1;if?(get_file_size(infd,?&insize))return?1;ret?=?copy_file(&ring,?insize);close(infd);close(outfd);io_uring_queue_exit(&ring);return?ret; }其他說明
代碼中實(shí)現(xiàn)了三個函數(shù)：
copy_file()：高層復(fù)制循環(huán)邏輯；它會調(diào)用 queue_rw_pair(ring, this_size, offset) 來構(gòu)造 SQE pair；并通過一次 io_uring_submit() 調(diào)用將所有構(gòu)建的 SQE pair 提交。
這個函數(shù)維護(hù)了一個最大 DQ 數(shù)量的 inflight SQE，只要數(shù)據(jù) copy 還在進(jìn)行中；否則，即數(shù)據(jù)已經(jīng)全部讀取完成，就開始等待和收割所有的 CQE。
queue_rw_pair() 構(gòu)造一個 read-write SQE pair.
read SQE 的 IOSQE_IO_LINK flag 表示開始一個 chain，write SQE 不用設(shè)置這個 flag，標(biāo)志著這個 chain 的結(jié)束。用戶 data 字段設(shè)置為同一個 data 描述符，并且在隨后的 completion 處理中會用到。
handle_cqe() 從 CQE 中提取之前由 ?queue_rw_pair() 保存的 data 描述符，并在描述符中記錄處理進(jìn)展（index）。
如果之前請求被取消，它還會重新提交 read-write pair。
一個 CQE pair 的兩個 member 都處理完成之后（index==2），釋放共享的 data descriptor。最后通知內(nèi)核這個 CQE 已經(jīng)被消費(fèi)。
4 io_uring 性能壓測（基于 fio）
對于已經(jīng)在使用 linux-aio 的應(yīng)用，例如 ScyllaDB，不要期望換成 io_uring 之后能獲得大幅的性能提升，這是因?yàn)?#xff1a;io_uring 性能相關(guān)的底層機(jī)制與 linux-aio 并無本質(zhì)不同（都是異步提交，輪詢結(jié)果）。
在此，本文也希望使讀者明白：io_uring ?首先和最重要的貢獻(xiàn)在于：將 linux-aio 的所有優(yōu)良特性帶給了普羅大眾（而非局限于數(shù)據(jù)庫這樣的細(xì)分領(lǐng)域）。
4.1 測試環(huán)境
本節(jié)使用 fio 測試 4 種模式：
synchronous reads
posix-aio (implemented as a thread pool)
linux-aio
io_uring
硬件：
NVMe 存儲設(shè)備，物理極限能打到 ?3.5M IOPS。
8 核處理器
4.2 場景一：direct I/O 1KB 隨機(jī)讀（繞過 page cache）
第一組測試中，我們希望所有的讀請求都能 命中存儲設(shè)備（all reads to hit the storage）， 完全繞開操作系統(tǒng)的頁緩存（page cache）。
測試配置：
8 個 CPU 執(zhí)行 72 fio job，
每個 job 隨機(jī)讀取 4 個文件，
iodepth=8（number of I/O units to keep in flight against the file.）。
這種配置 保證了 CPU 處于飽和狀態(tài)，便于觀察 I/O 性能。如果 CPU 數(shù)量足夠多，那每組測試都可能會打滿設(shè)備帶寬，結(jié)果對 I/O 壓測就沒意義了。
表 1. Direct I/O（繞過系統(tǒng)頁緩存）：1KB 隨機(jī)讀，CPU 100% 下的 I/O 性能
| backend | IOPS | context switches | IOPS ±% vs io_uring |
| sync | 814,000 | 27,625,004 | -42.6% |
| posix-aio (thread pool) | 433,000 | 64,112,335 | -69.4% |
| linux-aio | 1,322,000 | 10,114,149 | -6.7% |
| io_uring (basic) | 1,417,000 | 11,309,574 | — |
| io_uring (enhanced) | 1,486,000 | 11,483,468 | 4.9% |
幾點(diǎn)分析：
io_uring 相比 linux-aio 確實(shí)有一定提升，但并非革命性的。
開啟高級特性，例如 buffer & file registration 之后性能有進(jìn)一步提升 —— 但也還 沒有到為了這些性能而重寫整個應(yīng)用的地步，除非你是搞數(shù)據(jù)庫研發(fā)，想榨取硬件的最后一分性能。
io_uring and linux-aio ?都比同步 read 接口快 2 倍，而后者又比 posix-aio 快 2 倍 —— 初看有點(diǎn)差異。但看看 上下文切換次數(shù)，就不難理解為什么 posix-aio 這么慢了。
同步 read 性能差是因?yàn)?#xff1a;在這種沒有 page cache 的情況下，每次 read 系統(tǒng)調(diào)用都會阻塞，因此就會涉及一次上下文切換。
posix-aio 性能更差是因?yàn)?#xff1a;不僅內(nèi)核和應(yīng)用程序之間要頻繁上下文切換，線程池的 多個線程之間也在頻繁切換。
4.2 場景二：buffered I/O 1KB 隨機(jī)讀（數(shù)據(jù)提前加載到內(nèi)存，100% hot cache）
第二組測試 buffered I/O：
將文件數(shù)據(jù)提前加載到內(nèi)存，然后再測隨機(jī)讀。
由于 數(shù)據(jù)全部在 page cache，因此 同步 read 永遠(yuǎn)不會阻塞。
這種場景下，我們預(yù)期 同步讀和 io_uring 的性能差距不大（都是最好的）。
其他測試條件不變。
表 2. Buffered I/O（數(shù)據(jù)全部來自 page cache，100% hot cache）：1KB 隨機(jī)讀，100% CPU 下的 I/O 性能
| Backend | IOPS | context switches | IOPS ±% vs io_uring |
| sync | 4,906,000 | 105,797 | -2.3% |
| posix-aio (thread pool) | 1,070,000 | 114,791,187 | -78.7% |
| linux-aio | 4,127,000 | 105,052 | -17.9% |
| io_uring | 5,024,000 | 106,683 | — |
結(jié)果分析：
同步讀和 io_uring 性能差距確實(shí)很小，二者都是最好的。
但注意， **實(shí)際的應(yīng)用**不可能一直 100% 時間執(zhí)行 IO 操作，因此 基于同步讀的真實(shí)應(yīng)用性能 還是要比基于 io_uring 要差的，因?yàn)?io_uring 會將多個系統(tǒng)調(diào)用批處理化。
posix-aio 性能最差，直接原因是 上下文切換次數(shù)太多，這也和場景相關(guān)：在這種 ?CPU 飽和的情況下，它的線程池反而是累贅，會完全拖慢性能。
linux-aio 并 不是針對 buffered I/O 設(shè)計(jì)的，在這種 page cache 直接返回的場景， 它的 異步接口反而會造成性能損失 —— 將操作分 為 dispatch 和 consume 兩步不但沒有性能收益，反而有額外開銷。
4.3 性能測試小結(jié)
最后再次提醒，本節(jié)是極端應(yīng)用/場景（ 100% CPU + 100% cache miss/hit）測試， 真實(shí)應(yīng)用的行為通常處于同步讀和異步讀之間：時而一些阻塞操作，時而一些非阻塞操作。但不管怎么說，用了 io_uring 之后，用戶就無需擔(dān)心同步和異步各占多少比例了，因?yàn)樗?在任何場景下都表現(xiàn)良好。
如果操作是非阻塞的，io_uring 不會有額外開銷；
如果操作是阻塞式的，也沒關(guān)系，io_uring 是完全異步的，并且不依賴線程池或昂貴的上下文切換來實(shí)現(xiàn)這種異步能力；
本文測試的都是隨機(jī)讀，但對 其他類型的操作，io_uring 表現(xiàn)也是非常良好的。例如：
打開/關(guān)閉文件
設(shè)置定時器
通過 network sockets 傳輸數(shù)據(jù)
而且 使用的是同一套 io_uring 接口。
4.4 ScyllaDB 與 io_uring
Scylla 重度依賴 direct I/O，從一開始就使用 linux-aio。在我們轉(zhuǎn)向 io_uring 的過程中，最開始測試顯示對某些 workloads，能取得 50% 以上的性能提升。但 深入研究之后發(fā)現(xiàn)，這是因?yàn)槲覀?之前的 linux-aio 用的不夠好。這也揭示了一個 經(jīng)常被忽視的事實(shí)：獲得高性能沒有那么難（前提是你得弄對了）。在對比 io_uring 和 linux-aio 應(yīng)用之后，我們 很快改進(jìn)了一版，二者的性能差距就消失了。但坦率地說，解決這個問題 需要一些工作量，因?yàn)橐膭右粋€已經(jīng)使用 了很多年的基于 linux-aio 的接口。而對 io_uring 應(yīng)用來說，做類似的改動是輕而 易舉的。
以上只是一個場景，io_uring 相比 linux-aio 的 **優(yōu)勢**是能應(yīng)用于 file I/O 之外的場景。此外，它還自帶了特殊的 高性能[19] 接口，例如 buffer registration、file registration、輪詢模式等等。
啟用 io_uring 高級特性之后，我們看到性能確實(shí)有提升：Intel Optane 設(shè)備，單個 CPU ?讀取 512 字節(jié)，觀察到 5% 的性能提升。與 表 1 & 2 對得上。雖然 5% 的提升 看上去不是太大，但對于希望壓榨出硬件所有性能的數(shù)據(jù)庫來說，還是非常寶貴的。
| linux-aio: Throughput ? ? ? ? : ? ? ?330 MB/s | io_uring, with buffer and file registration and poll: Throughput ? ? ? ? : ? ? ?346 MB/s |
| 使用 1 個 CPU 從 Intel Optane 設(shè)備讀取 512 字節(jié)。1000 并發(fā)請求。linux-aio 和 io_uring basic interface 性能差異很小。? 但啟用 io_uring 高級特性后，有 5% 的性能差距。 | |
5 eBPF
eBPF 也是一個 事件驅(qū)動框架（因此也是異步的），允許用戶空間程序動態(tài)向內(nèi)核注入字節(jié)碼，主要有兩個使用場景：
Networking：本站[20] 已經(jīng)有相當(dāng)多的文章
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ù)，例如：
Trace how much time an application spends sleeping, and what led to those sleeps. (wakeuptime)
Find all programs in the system that reached a particular place in the code (trace)
Analyze network TCP throughput aggregated by subnet (tcpsubnet)
Measure how much time the kernel spent processing softirqs (softirqs)
Capture information about all short-lived files, where they come from, and for how long they were opened (filelife)
6 結(jié)束語
io_uring 和 eBPF 這兩大特性 將給 Linux 編程帶來革命性的變化。有了這兩個特性的加持，開發(fā)者就能更充分地利用 Amazon i3en meganode systems[22]之類的多核/多處理器系統(tǒng)，以及 Intel Optane 持久存儲[23]之類的 us 級延遲存儲設(shè)備。
參考資料
Efficient IO with io_uring[24], pdf
Ringing in a new asynchronous I/O API[25], lwn.net
The rapid growth of io_uring[26], lwn.net
System call API[27], manpage
引用鏈接
[1]
How io_uring and eBPF Will Revolutionize Programming in Linux: https://thenewstack.io/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux
[2]An Introduction to the io_uring Asynchronous I/O Framework: https://medium.com/oracledevs/an-introduction-to-the-io-uring-asynchronous-i-o-framework-fad002d7dfc1
[3]淺析開源項(xiàng)目之 io_uring: https://zhuanlan.zhihu.com/p/361955546
[4]Is there really no asynchronous block I/O on Linux?: https://stackoverflow.com/questions/13407542/is-there-really-no-asynchronous-block-i-o-on-linux
[5]thread pool: https://en.wikipedia.org/wiki/Thread_pool
[6]并不想使用操作系統(tǒng)的 page cache: https://www.scylladb.com/2018/07/26/how-scylla-data-cache-works
[7]Intel Optane: https://pcper.com/2018/12/intels-optane-dc-persistent-memory-dimms-push-latency-closer-to-dram
[8]Linux AIO 甚至支持了: https://lwn.net/Articles/742978/
[9]to support opening files asynchronously: https://lwn.net/Articles/671657/
[10]很多可能的原因都會導(dǎo)致它阻塞: https://lwn.net/Articles/724198
[11]aio: support for IO polling: https://lwn.net/ml/linux-fsdevel/20181221192236.12866-9-axboe@kernel.dk
[12]一篇文章: https://www.scylladb.com/2018/01/07/cost-of-avoiding-a-meltdown/
[13]有一次關(guān)于 async 的分享: https://www.scylladb.com/2020/03/26/avi-kivity-at-core-c-2019
[14]連系統(tǒng)調(diào)用都省了: https://www.phoronix.com/scan.php?page=news_item&px=Linux-io_uring-Fast-Efficient
[15]manpage: https://github.com/axboe/liburing/tree/master/man
[16]liburing: https://github.com/axboe/liburing/
[17]io_uring-test.c: https://github.com/axboe/liburing/blob/liburing-2.0/examples/io_uring-test.c
[18]詳細(xì)解釋: https://www.mankier.com/2/io_uring_enter#Description-IOSQE_IO_LINK
[19]高性能: https://www.p99conf.io/
[20]本站: https://arthurchiao.art
[21]bcc: https://github.com/iovisor/bcc
[22]Amazon i3en meganode systems: https://www.scylladb.com/2019/05/28/aws-new-i3en-meganode
[23]Intel Optane 持久存儲: https://www.scylladb.com/2017/09/27/intel-optane-scylla-providing-speed-memory-database-persistency
[24]Efficient IO with io_uring: https://kernel.dk/io_uring.pdf
[25]Ringing in a new asynchronous I/O API: https://lwn.net/Articles/776703/
[26]The rapid growth of io_uring: https://lwn.net/Articles/810414/
[27]System call API: https://github.com/axboe/liburing/tree/master/man
原文鏈接：https://arthurchiao.art/blog/intro-to-io-uring-zh/
- END -
看完一鍵三連在看，轉(zhuǎn)發(fā)，點(diǎn)贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
滴水石穿非一日之功
深入理解 Linux的 I/O 系統(tǒng)
實(shí)戰(zhàn)|QUIC協(xié)議助力騰訊業(yè)務(wù)提速30%
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 求點(diǎn)贊，在看，分享三連
總結(jié)
以上是生活随笔為你收集整理的深入理解Linux异步I/O框架 io_uring的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux内存占用分析的几个方法，你知道
- 下一篇： 计算机专业有什么血泪建议吗？