Persistent Memory（PMem）

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

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

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

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

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

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

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

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

然而 CLFLUSH 并不是為 PMem 設(shè)計的。CLFLUSH 指令一次只能 Flush 一個 Cache Line，且只能串行執(zhí)行，所以執(zhí)行效率非常低。為了解決 CLFLUSH 效率低的問題，Intel 推出了一個新的指令 CLFLUSHOPT，從字面意思上看就是 CLFLUSH 的優(yōu)化版本。CLFLUSHOPT 和 CLFLUSH 相比，多個 CLFLUSHOPT 指令可以并發(fā)執(zhí)行?？梢源蟠筇岣?Cache Line Flush 的效率。當(dāng)然，CLFLUSHOPT 后面還需要跟隨一個 SFENCE 指令，以保證 Flush 執(zhí)行完成。

和 CLFLUSHOPT 對應(yīng)的，是 CLWB 指令，CLWB 和 CLFLUSHOPT 的區(qū)別是，CLWB 指令執(zhí)行完成后，數(shù)據(jù)還保持在 CPU Cache 里，如果再次訪問數(shù)據(jù)，就可以保證 Cache Hit，而 CLFLUSHOPT 則相反，指令執(zhí)行完成后，CPU Cache 中將不再保存數(shù)據(jù)。

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

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

為了簡化使用 PMem 的復(fù)雜度，Intel 成立了 PMDK 項目，提供了大量的封裝好的接口和數(shù)據(jù)結(jié)構(gòu)，這里我就不一一介紹了。

PMem 發(fā)布以后，不少的機構(gòu)都對它的實際性能做了測試，因為畢竟之前大家都是用內(nèi)存來模擬 PMem 的，得到的實驗結(jié)果并不準(zhǔn)確。其中 UCSD 發(fā)表的 “Basic Performance Measurements of the Intel Optane DC Persistent Memory Module” 是比較有代表性的。這篇文章幫我們總結(jié)了 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

如果你正在開發(fā)針對 PMem 的程序，一定要仔細(xì)理解。

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

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

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

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

關(guān)于 PMem 的使用場景，其實有很多，例如：

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

OS 不感知，由硬件負(fù)責(zé)將 DRAM 作為 Cache，PMem 作為主存

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

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

關(guān)于 PMem 的其他部分，我們后續(xù)還會有專門的文章介紹。

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

Distributed Consensus and Consistency

Distributed Consensus 在過去十年已經(jīng)被大家研究的比較透徹了，目前各種 Paxos，Raft 已經(jīng)的實現(xiàn)已經(jīng)被廣泛應(yīng)用在各種生產(chǎn)環(huán)境了，各種細(xì)節(jié)的優(yōu)化也層出不窮。

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

說到 Distributed Consensus，就離不開 Consistency。Distributed Consensus 是實現(xiàn) Strong Consistency 的非常經(jīng)典的做法，但是，并不是唯一的做法。

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

實現(xiàn) Strong Consistency 的方法還有很多。在過去一段時間里面，我認(rèn)為最經(jīng)典的要數(shù) Amazon 的 Aurora。

Amazon Aurora 目前共發(fā)表了兩篇文章。第一篇是 2017 年在 SIGMOD 上發(fā)表的 “Amazon Aurora： Design Considerations for High Throughput Cloud-Native Relational Databases”，另一篇是在 2018 年的 SIGMOD 上發(fā)表了一篇論文 “Amazon Aurora： On Avoiding Distributed Consensus for I/Os， Commits， and Membership Changes”。第二篇論文主要講述了他們?nèi)绾卧诓皇褂?Distributed Consensus 的情況下，達(dá)到 Strong Consistency 的效果。

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

我們假設(shè)當(dāng)前計算端的狀態(tài)是 S0，此時我們收到了一個請求，要把狀態(tài)變更為 S1。為了完成這個變更，存儲端會發(fā)起了一次 Distributed Consensus。如果成功，則計算端把狀態(tài)變更為 S1；如果失敗，則狀態(tài)維持在 S0 不變?？梢钥吹酱鎯Χ讼蛴嬎愣朔祷氐臓顟B(tài)只有成功和失敗兩個狀態(tài)，而實際上存儲端內(nèi)部會有更多的狀態(tài)，例如 5 個節(jié)點里面 3 個成功了，1 個失敗了，1 個超時了。而這些狀態(tài)都被存儲端屏蔽了，計算端不感知。這就導(dǎo)致計算端必須等待存儲端完成 Distributed Consensus 以后，才能繼續(xù)向前推進。在正常情況下不會有問題，但一旦存儲端發(fā)生異常，計算端必須要等待存儲端完成 Leader Election 或 Membership Change，導(dǎo)致整個計算端被阻塞住。

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

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

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

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

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

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

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

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

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

如果你的應(yīng)用程序?qū)儆趯懚嘧x少的，那么這種方法就可以避免了大量無用的 Replication 操作，僅在必要的時候執(zhí)行 Replication，也就是讀的時候。這樣既保證了 Strong Consistency，又保證了 Performance。真是不得不佩服 Remzi，把 Consensus，Consistency，Durability 研究的太透徹了。

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

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

Distributed Shared Memory and Heterogeneous computing

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

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

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

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

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

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

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

在工業(yè)界中，盡管目前還沒有看到 DSM 的成功案例，但是目前已經(jīng)開始看到一些相關(guān)的技術(shù)出現(xiàn)。這里我們會重點關(guān)注一下總線（Bus）技術(shù)。

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

為了適應(yīng)逐漸增加的異構(gòu)計算場景，各個廠商開始籌劃推出新的總線技術(shù)，這包括：

來自 Intel 的 Compute Express Link（CXL）

來自 IBM 的 Coherent Accelerator Interface（CAPI）

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

來自 AMD 的 Infinity Fabric

來自 NVIDIA 的 NVLink

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

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

CXL 協(xié)議中定義了 3 種子協(xié)議：

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

CXL.cache：用于設(shè)備訪問主存

CXL.memory：用于 CPU 訪問設(shè)備內(nèi)存

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

CXL 1.0 將采用和 PCIe Gen5 向兼容的硬件標(biāo)準(zhǔn)，這樣一來硬件廠商不需要為適配不同協(xié)議而生產(chǎn)兩種不同接口的硬件設(shè)備，統(tǒng)一采用 PCIe Gen5 的標(biāo)準(zhǔn)就可以了。如果在設(shè)備協(xié)商階段發(fā)現(xiàn)對端支持 CXL 協(xié)議，那么就可以采用 CXL 協(xié)議運行，否則可以采用 PCIe Gen5 運行。

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

其他方面

Open-Channel SSD

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

LSM-Tree 優(yōu)化

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

Machine Learning and Systems

盡管兩年前開始有 Machine Learning For Systems 的相關(guān)工作，但是過去兩年一直沒有什么實質(zhì)性的進展，反倒是 Systems for Machine Learning 有一些和 GPU 任務(wù)調(diào)度相關(guān)的工作。

VirtIO without Virt

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

Linux Kernel

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