Persistent Memory（PMem）

PMem 在 2018 年的時候還僅限于學術界的探討，而如今已經來到了工業界。Intel 在 2019 年 4 月份發布了第一款 Intel Optane DC Persistent Memory（內部產品代號 Apache Pass），可以說是一個劃時代的事件。如果你完全沒有聽說過 PMem，那么可以先通過我之前的文章了解一下。

我們先來看一下實物的樣子

是的，DIMM 接口，看起來就像內存。所以很多人會把 Optane PMem 和 Optane SSD 弄混，因為都叫 Optane。實際上 Optane SSD 是 NVMe 接口，走 PCIe 總線。由于接口和總線不同，Optane PMem 和 Optane SSD 的使用方式也完全不同的。

目前單條（因為長得像內存，所以就用“條”來做量詞了）容量一共有三種選擇：128G、256G、512G，價格還是相當貴的。

這里我想強調的是：PMem 并不是更慢的內存，也不是更快的 SSD，PMem 就是 PMem，他有大量屬于自己的特性。為了使用好 PMem，我們還需要對 PMem 了解更多。

首先，由于 PMem 是 DIMM 接口，可以直接通過 CPU 指令訪問數據。讀取 PMem 的時候，和讀取一個普通的內存地址沒有區別，CPU Cache 會做數據緩存，所有關于內存相關的知識，例如 Cache Line 優化，Memory Order 等等在這里都是適用的。而寫入就更復雜了，除了要理解內存相關的特性以外，還需要理解一個重要的概念：Power-Fail Protected Domains。這是因為，盡管 PMem 設備本身是非易失的，但是由于有 CPU Cache 和 Memory Controller 的存在，以及 PMem 設備本身也有緩存，所以當設備掉電時，Data in-flight 還是會丟失。

針對掉電保護，Intel 提出了 Asynchronous DRAM Refresh（ADR）的概念，負責在掉電時把 Data in-flight 回寫到 PMem 上，保證數據持久性。目前 ADR 只能保護 iMC 里的 Write Pending Queue（WPQ）和 PMem 的緩存中的數據，但無法保護 CPU Cache 中的數據。在 Intel 下一代的產品中，將推出 Enhanced ADR（eADR），可以進一步做到對 CPU Cache 中數據的保護。

由于 ADR 概念的存在，所以簡單的 MOV 指令并不能保證數據持久化，因為指令結束時，數據很可能還停留在 CPU Cache 中。為了保證數據持久化，我們必須調用 CLFLUSH 指令，保證 CPU Cache Line 里的數據寫回到 PMem 中。

然而 CLFLUSH 并不是為 PMem 設計的。CLFLUSH 指令一次只能 Flush 一個 Cache Line，且只能串行執行，所以執行效率非常低。為了解決 CLFLUSH 效率低的問題，Intel 推出了一個新的指令 CLFLUSHOPT，從字面意思上看就是 CLFLUSH 的優化版本。CLFLUSHOPT 和 CLFLUSH 相比，多個 CLFLUSHOPT 指令可以并發執行。可以大大提高 Cache Line Flush 的效率。當然，CLFLUSHOPT 后面還需要跟隨一個 SFENCE 指令，以保證 Flush 執行完成。

和 CLFLUSHOPT 對應的，是 CLWB 指令，CLWB 和 CLFLUSHOPT 的區別是，CLWB 指令執行完成后，數據還保持在 CPU Cache 里，如果再次訪問數據，就可以保證 Cache Hit，而 CLFLUSHOPT 則相反，指令執行完成后，CPU Cache 中將不再保存數據。

此外 Non-temporal stores（NTSTORE）指令（經專家更提醒，這是一個 SSE2 里面就添加的指令，并不是一個新指令）可以做到數據寫入的時候 bypass CPU Cache，這樣就不需要額外的 Flush 操作了。NTSTORE 后面也要跟隨一個 SFENCE 指令，以保證數據真正可以到達持久化區域。

看起來很復雜對吧，這還只是個入門呢，在 PMem 上寫程序的復雜度相當之高。Intel 最近出了一本書 “Programming Persistent Memory”，專門介紹如何在 PMem 上進行編程，一共有 400 多頁，有興趣的小伙伴可以讀一讀。

為了簡化使用 PMem 的復雜度，Intel 成立了 PMDK 項目，提供了大量的封裝好的接口和數據結構，這里我就不一一介紹了。

PMem 發布以后，不少的機構都對它的實際性能做了測試，因為畢竟之前大家都是用內存來模擬 PMem 的，得到的實驗結果并不準確。其中 UCSD 發表的 “Basic Performance Measurements of the Intel Optane DC Persistent Memory Module” 是比較有代表性的。這篇文章幫我們總結了 23 個 Observation，其中比較重要的幾點如下：

The read latency of random Optane DC memory loads is 305 ns This latency is about 3× slower than local DRAM

Optane DC memory latency is significantly better （2×） when accessed in a sequential pattern. This result indicates that Optane DC PMMs merge adjacent requests into a single 256 byte access

Our six interleaved Optane DC PMMs’ maximum read bandwidth is 39.4 GB/sec， and their maximum write bandwidth is 13.9 GB/sec. This experiment utilizes our six interleaved Optane DC PMMs， so accesses are spread across the devices

Optane DC reads scale with thread count; whereas writes do not. Optane DC memory bandwidth scales with thread count， achieving maximum throughput at 17 threads. However， four threads are enough to saturate Optane DC memory write bandwidth

The application-level Optane DC bandwidth is affected by access size. To fully utilize the Optane DC device bandwidth， 256 byte or larger accesses are preferred

Optane DC is more affected than DRAM by access patterns. Optane DC memory is vulnerable to workloads with mixed reads and writes

Optane DC bandwidth is significantly higher （4×） when accessed in a sequential pattern. This result indicates that Optane DC PMMs contain access to merging logic to merge overlapping memory requests — merged， sequential， accesses do not pay the write amplification cost associated with the NVDIMM’s 256 byte access size

如果你正在開發針對 PMem 的程序，一定要仔細理解。

PMem 的好處當然很多，延遲低、峰值帶寬高、按字節訪問，這沒什么好說的，畢竟是 DIMM 接口，價格也在那里擺著。

這里我想給大家提幾個 PMem 的坑，這可能是很多測試報告里面不會提到的，而是我們親身經歷過的，供大家參考：

盡管峰值帶寬高，但單線程吞吐率低，甚至遠比不上通過 SPDK 訪問 NVMe 設備。舉例來說，Intel 曾發布過一個報告，利用 SPDK，在 Block Size 為 4KB 的情況下，單線程可以達到 10 Million 的 IOPS。而根據我們測試的結果，在 PMem 上，在 Block Size 為 4KB 時，單線程只能達到 1 Million 的 IOPS。這是由于目前 PMDK 統一采用同步的方式訪問數據，所有內存拷貝都由 CPU 來完成，導致 CPU 成為了性能瓶頸。為了解決這個問題，我們采用了 DMA 的方式進行訪問，極大的提高了單線程訪問的效率。關于這塊信息，我們將在未來用單獨的文章進行講解。

另一個坑就是，跨 NUMA Node 訪問時，效率受到比較大的影響。在我們的測試中發現，跨 NUMA Node 的訪問，單線程只提供不到 1GB/s 的帶寬。所以一定要注意保證數據訪問是 Local 的。

關于 PMem 的使用場景，其實有很多，例如：

作為容量更大，價格更便宜的主存，在這種情況下，PMem 實際上并不 Persitent。這里又有兩種模式：

OS 不感知，由硬件負責將 DRAM 作為 Cache，PMem 作為主存

OS 感知，將 PMem 作為一個獨立的 memory-only NUMA Node，目前已經被 Linux Kernel 支持，Patchset

作為真正的 PMem，提供可持久化存儲能力

關于 PMem 的其他部分，我們后續還會有專門的文章介紹。

順便劇透一下，我們即將在今年上半年發布的 SMTX ZBS 4.5 版本中，包含了針對 PMem 的大量優化工作，和上一個版本相比，整體延遲可以降低超過 80%~

Distributed Consensus and Consistency

Distributed Consensus 在過去十年已經被大家研究的比較透徹了，目前各種 Paxos，Raft 已經的實現已經被廣泛應用在各種生產環境了，各種細節的優化也層出不窮。

如果你想系統性的學習一下 Distributed Consensus 的話，那么推薦你看一篇劍橋女博士 Heidi Howard 的畢業論文“Distributed consensus revised”。這篇論文可以說是把過去幾十年大家在 Distributed Consensus 上的工作做了一個大而全總結。通過總結前人的工作，整理出了一個 Distributed Consensus 的模型，并且逐個調節模型中的約束條件，從而遍歷了幾乎所有可能的優化算法，可以說是庖丁解牛，非常適合作為 Distributed Consensus 的入門文章。

說到 Distributed Consensus，就離不開 Consistency。Distributed Consensus 是實現 Strong Consistency 的非常經典的做法，但是，并不是唯一的做法。

Distributed Consensus 只是手段，Strong Consistency 才是目的。

實現 Strong Consistency 的方法還有很多。在過去一段時間里面，我認為最經典的要數 Amazon 的 Aurora。

Amazon Aurora 目前共發表了兩篇文章。第一篇是 2017 年在 SIGMOD 上發表的 “Amazon Aurora： Design Considerations for High Throughput Cloud-Native Relational Databases”，另一篇是在 2018 年的 SIGMOD 上發表了一篇論文 “Amazon Aurora： On Avoiding Distributed Consensus for I/Os， Commits， and Membership Changes”。第二篇論文主要講述了他們如何在不使用 Distributed Consensus 的情況下，達到 Strong Consistency 的效果。

為了介紹 Aurora，我們先來簡單看一下通常 Distributed Consensus 是如何做到 Strong Consistency 的。

我們假設當前計算端的狀態是 S0，此時我們收到了一個請求，要把狀態變更為 S1。為了完成這個變更，存儲端會發起了一次 Distributed Consensus。如果成功，則計算端把狀態變更為 S1；如果失敗，則狀態維持在 S0 不變。可以看到存儲端向計算端返回的狀態只有成功和失敗兩個狀態，而實際上存儲端內部會有更多的狀態，例如 5 個節點里面 3 個成功了，1 個失敗了，1 個超時了。而這些狀態都被存儲端屏蔽了，計算端不感知。這就導致計算端必須等待存儲端完成 Distributed Consensus 以后，才能繼續向前推進。在正常情況下不會有問題，但一旦存儲端發生異常，計算端必須要等待存儲端完成 Leader Election 或 Membership Change，導致整個計算端被阻塞住。

而 Aurora 則打破了這個屏障。Aurora 的計算端可以直接向存儲端發送寫請求，并不要求存儲端節點之間達成任何的 Consensus。

典型的 Aurora 實例包含 6 個存儲節點，分散在 3 個 AZ 中。每個存儲節點都維護了 Log 的列表，以及 Segment Complete LSN（SCL），也就是已經持久化的 LSN。存儲節點會將 SCL 匯報給計算節點。計算節點會在 6 個節點中，找出 4 個最大的 SCL，并將其中最小的值作為 Protection Group Complete LSN（PGCL）。而 PGCL 就是 Aurora 實例已經達成 Consistency Point。

看上去好像和 Multi-Paxos 也有些相似？是的，但 Aurora 并不要求存儲節點之間達成任何的 Consensus，發生故障的時候，存儲節點不需要參與 Leader Election，也不需要等待所有的日志復制完成。這意味著計算節點基本上永遠不會被阻塞。

Aurora 的精妙之處在于把 Distributed Consensus 從存儲節點中抽離出來了，存儲節點只是單純的負責存儲工作就好了，而 Consensus 由計算節點來完成。那這樣看上去好像又和 PacificA 很相似？是的，我認為在整體思路上，Aurora 和 PacificA 是非常相似的。我個人認為 Consensus 和存儲節點的解耦會是未來的一個趨勢。

除了 Aurora 以外，Remzi 團隊在 FAST 2020 上的 Best Paper：“Strong and Efficient Consistency with Consistency-Aware Durability”，我認為也是非常有意思的一篇文章。

通常來說，我們在考慮 Consistency 的時候，都會結合 Durability 一起考慮。需要 Strong Consistency，就會用 Distributed Consensus，或者其他的 Replication 方式完成一次 Quorum Write，保證了 Strong Consistency 的同時，也保證了 Durability，代價就是性能差；如果只需要 Weak Consistency，那么就不需要立刻完成 Quorum Write，只需要寫一個副本就可以了，然后再異步完成數據同步，這樣性能會很好，但是由于沒有 Quorum Write，也就喪失了 Durability 和 Consistency。所以大家一直以來的一個共識，就是 Strong Consistency 性能差，Weak Consistency 性能好。

那有沒有一種方法既能保證 Strong Consistency，同時又保證 Performance 呢？Remzi 在這篇論文中提出了 “Consistency-Aware Durability”（CAD）的方法，把 Consistency 和 Durability 解耦，放棄了部分 Durability，來保證 Strong Consisteny 和 Performance。實現的方法可以用一句話總結，就是 Replicate on Read。

在 Strong Consistency 中，有一個很重要的要求就是 Monotonic Reads，當讀到了一個新版本的數據后，再也不會讀到老版本的數據。但換一個角度思考，如果沒有讀發生，是不存在什么 Monotonic Reads 的，也就不需要做任何為了為了保證 Consistency 的工作（是不是有點像薛定諤的貓？）。

我們在寫時做 Replication，完全是為了保證 Durability，順便完成了保證 Consistency。如果我們可以犧牲 Durability，那么在寫入時，我們完全不需要做 Replication，寫單復本就可以了。我們只需要在需要 Consistency 的時候（也就是讀的時候）完成 Consistency 的操作就可以了（也就是 Replication）。所以我把這種方法叫做 Replicate On Read。

如果你的應用程序屬于寫多讀少的，那么這種方法就可以避免了大量無用的 Replication 操作，僅在必要的時候執行 Replication，也就是讀的時候。這樣既保證了 Strong Consistency，又保證了 Performance。真是不得不佩服 Remzi，把 Consensus，Consistency，Durability 研究的太透徹了。

可能做系統的同學覺得犧牲 Durability 好像不可接受，但是在類似互聯網應用的場景中，一些臨時數據的 Durability 其實是不太重要的，而 Consistency 才是影響體驗的核心因素。我們以打車舉例，如果你看到司機距離你的位置一開始是 1 公里，然后忽然又變成了 3 公里，這很可能是后臺的 NoSQL 數據庫發生了一次故障切換，而從節點中保存的數據是一個老數據，導致破壞了 Monotonic Reads。而司機位置這種數據是完全沒有必要保證 Durability 的，那么在這種情況下利用比較小的代價來保證 Monotonic Reads，將極大地改善用戶的體驗，你會看到司機和你的距離會越來越近，而不是忽遠忽近。

另外再推薦給大家兩篇論文，一篇是 Raft 作者 John Ousterhout 大神的新作 “Exploiting Commutativity For Practical Fast Replication”，還有一篇是用 Raft 實現 Erasure Code “CRaft： An Erasure-coding-supported Version of Raft for Reducing Storage Cost and Network Cost”。有興趣的同學可以自己看一下，這里我就不做介紹了。

Distributed Shared Memory and Heterogeneous computing

在開始之前，我們首先來回顧一下計算機的發展歷史。到今天為止，主流的計算機都是在馮諾依曼架構下發展的，一切的設計都圍繞著 CPU、內存進行。當 CPU、內存的能力不足時，就通過總線（Bus），不斷地對他們的能力進行擴展，例如磁盤、GPU 等等。隨著 CPU 速度不斷升級，總線的速度也在不斷地升級，以匹配 CPU 的運算速度。同時，為了安全高效的完成 CPU 以及外設之間的通信，產生了例如 DMA、IOMMU 等技術。而總線受限于物理條件，通常只能進行非常短距離的通信，CPU 能直接訪問的所有的設備都需要集成在主板上，也就是我們今天看到的主機。

在早期 CPU 的處理能力還非常弱的時候，單個 CPU 無法勝任大規模計算任務。這個時候出現了兩種發展的流派，一種是 Shared Memory，也就是在單機內擴展 CPU 的數量，所有 CPU 都共享相同的內存地址空間；另一種是 Distributed Memory，也可以理解為多機，每臺機器的 CPU 有獨立的內存和獨立的地址空間，程序之間通過 Message-Passing 的方式進行通信。Shared Memory 技術對于硬件的要求較高，需要在處理器之間實現 Cache Coherence，而軟件層面的改動較為容易，早期的典型代表就是 Mainframe Computer，也就是俗稱的大型機；而 Distributed Memory 則對硬件的要求較低，但是軟件需要采用 Message-Passing 的方式進行重寫，例如早年的 MPI 類的程序，主要應用在 HPC 領域。由于 Mainframe 的硬件成本太高，MPI 逐漸成為了主流。

在上世紀八九十年代的時候，曾經流行了一陣 Distributed Shared Memory（DSM）技術，也就是分布式共享內存。DSM 通過操作系統的內存管理系統把各個獨立服務器上的內存地址連接到一起，組成連續的內存地址，使得應用程序可以更方便的做數據共享。但 DSM 技術一直沒有發展起來，主要是受限于不斷提升的 CPU 頻率和當時的網絡速度越來越不匹配，導致 DSM 的通信成本過高，無法被普及。

到了 2000 年以后，CPU 的發展逐漸遇到瓶頸，單核計算性能已經不再可能有大的突破，CPU 逐漸轉向多核方向發展，個人電腦也用上了 Shared Memory 技術。而隨著大數據對算力和存儲能力的要求，Distributed Memory 技術也越來越廣泛地被使用，例如 MapReduce 和 Spark 這種計算框架就是典型的代表。

到了最近幾年，CPU 速度依然沒有明顯的突破，但網絡速度卻在發生翻天覆地的變化。包括 IB 和以太網都可以達到 200Gb 的帶寬和 us 級別的延遲（據說目前已經在制定 800Gb 的技術標準），以及 RDMA 技術的普及，使得 DSM 技術又再次被大家提起。

OSDI ‘18 的 Best Paper “LegoOS： A Disseminated， Distributed OS for Hardware Resource Disaggregation” 就是一種 DSM 系統，只不過除了 CPU 和內存外，LegoOS 還包括了對存儲的討論。在論文中，作者把 CPU、Memory 和 Storage 分別抽象為 pComponent、mComponent 和 sComponent，這些設備之間通過 RDMA 網絡連接在一起。LegoOS 向用戶提供了 vNode 的概念，每個 vNode 類似一個虛擬機，可以包含一個或多個 pComponent，mComponent 和 sComponent。而每個 Component 同時也可以服務于多個 vNode。LegoOS 會負責對資源的隔離。由于具有統一的內存地址空間，且兼容 POSIX 接口，應用程序不需要被改寫就可以運行在 LegoOS 上。

LegoOS 是一個非常不錯的想法，但我認為在實現上會面臨著非常巨大的挑戰，一方面由于大部分的功能都需要依賴軟件來實現，延遲可能會受到一定的影響，另一方面是 LegoOS 沒有采用 Cache Coherence 的模型，而是用了 Message-Passing 的方式在各個 Component 之間進行通信。Message-Passing 可能是更優雅設計方案，但是如果真的想要在工業界中實現 LegoOS 這種思想，硬件廠商有需要根據 Message-Passing 來重新設計 Driver，這對于已有的硬件生態來說恐怕是很難接受的。

在工業界中，盡管目前還沒有看到 DSM 的成功案例，但是目前已經開始看到一些相關的技術出現。這里我們會重點關注一下總線（Bus）技術。

最近幾年，異構計算（heterogeneous computing）變得越來越常見，CPU 通過 PCIe 總線和 GPU、FPGA 等異構計算單元進行通訊。而由于 PCIe 總線誕生時間較早，不支持 Cache Coherence，所以為編寫異構計算的應用程序帶來了極大的復雜度。例如應用程序想要在 CPU 和 GPU 之間共享數據，或者 GPU 和 GPU 之間共享數據，必須自行處理可能產生的 Cache 一致性問題。

為了適應逐漸增加的異構計算場景，各個廠商開始籌劃推出新的總線技術，這包括：

來自 Intel 的 Compute Express Link（CXL）

來自 IBM 的 Coherent Accelerator Interface（CAPI）

來自 Xilinx 的 Cache Coherence Interconnect for Accelerator（CCIX）

來自 AMD 的 Infinity Fabric

來自 NVIDIA 的 NVLink

毫無例外，不同廠家的技術都提供了對 Cache Coherence 的支持，這正是 PCIe 總線所缺乏的，也是工業界所需要的。目前這場關于下一代總線的競爭還在進行中，但大家認為能笑到最后的恐怕還是 Intel 所支持的 CXL。

這里我們只對 CXL 做一個簡單的介紹。

CXL 協議中定義了 3 種子協議：

http://CXL.io：不提供 Cache Coherence 的 IO 訪問，類似于目前的 PCIe 協議

CXL.cache：用于設備訪問主存

CXL.memory：用于 CPU 訪問設備內存

例如對于一個 GPU 設備，可以通過 CXL 來進行 GPU 到 CPU，GPU 到 GPU 的數據交換。而由于 CXL 支持 Cache Coherence，這個過程將變得非常簡單，這無疑是一個重大的變化。而對于存儲設備來說，CXL 使得 PMem 無論是作為持久化內存還是易失性內存，都可以不僅僅局限在內存總線，而是可以通過 CXL.memory 和 CPU 進行通信。這意味著 PMem 未來不僅僅可以提供類似目前 NVMe 設備的熱插拔功能，還可以擺脫內存總線對散熱和功耗的限制。甚至更進一步，未來可能會出現 CXL over Fabric 的技術，CPU 可以通過 CXL 協議訪問遠端內存。

CXL 1.0 將采用和 PCIe Gen5 向兼容的硬件標準，這樣一來硬件廠商不需要為適配不同協議而生產兩種不同接口的硬件設備，統一采用 PCIe Gen5 的標準就可以了。如果在設備協商階段發現對端支持 CXL 協議，那么就可以采用 CXL 協議運行，否則可以采用 PCIe Gen5 運行。

CXL.cache 和 CXL.memory 組成了一個異構的 Shared Memory 系統，這對傳統的 Shared Memory 系統是一個極大的擴展，讓異構計算變得更加簡單。而 CXL over Fabric 可能會組成一個由硬件支持的 Distributed Shared Memory 系統，這將使 Memory-level Composable Infrastructure 成為可能。在未來的數據中心，很可能會出現專門用于池化內存的服務器，CPU、內存像樂高一樣搭建起來將真正成為現實。而這一切都有可能在未來的 5~10 年內發生。

其他方面

Open-Channel SSD

Open-Channel SSD 我在之前的文章中也做過介紹。和兩年前相比，目前已經被很多云廠商用起來了。相比于傳統 SSD，采用 Open-Channel SSD 的好處是可以定制 FTL，從而方便對特定的 Workload 進行優化。但 Open-Channel SSD 短期內恐怕只會被云廠商采用，畢竟大部分用戶沒有定制 FTL 的需求，通用的 FTL 就已經足夠了。而隨著 SPDK 中加入了對 FTL 的支持，也許未來會有廠商選擇直接在用戶態運行 Open-Channel SSD。

LSM-Tree 優化

過去兩年這方面的進展也比較少，我看過唯一相關的論文，是在 FAST ’19 上的一篇論文：SLM-DB： Single-Level Key-Value Store with Persistent Memory，對 PMem 上運行 LSM-Tree 進行優化。目前隨著 IO 設備的速度越來越快，大家都比較認可 LSM-Tree 已經從 IO Bound 轉移到 CPU Bound，LSM-Tree 的劣勢越來越明顯，這讓大家開始反思是否應該繼續使用 LSM-Tree 了。

Machine Learning and Systems

盡管兩年前開始有 Machine Learning For Systems 的相關工作，但是過去兩年一直沒有什么實質性的進展，反倒是 Systems for Machine Learning 有一些和 GPU 任務調度相關的工作。

VirtIO without Virt

VirtIO 是專門為虛擬化場景設計的協議框架。在 VirtIO 框架下，可以支持各種不同設備的虛擬化，包括 VirtIO-SCSI，VirtIO-BLK，VirtIO-NVMe，VirtIO-net，VirtIO-GPU，VirtIO-FS，VirtIO-VSock 等等。而 VirtIO 設備虛擬化的功能一直都是由軟件來完成的，之前主要是在 Qemu 里面，現在還有 VHost。而目前逐漸有硬件廠商開始嘗試原生支持 VirtIO 協議，把虛擬化的功能 Offload 到硬件上完成，這樣進一步降低 Host 上因虛擬化而產生的額外開銷。這也是 AWS Nitro 的核心技術之一，通過把 VirtIO Offload 給硬件，使得 Host 上的幾乎所有 CPU、內存資源都可以用于虛擬機，極大的降低了運營成本。

Linux Kernel

目前 Linux Kernel 已經來到了 5.0 的時代，近期比較重要的一個工作就是 IO_URING。關于 IO_URING，我們之前在文章中也做過介紹。IO_URING 和一年前相比又有了巨大的進步，目前除了支持 VFS 以外，也已經支持 Socket，為了提高性能還專門寫了新的 Work Queue。IO_URING 的終極目標是 one system call to rule them all，讓一切系統調用變成異步！