電子發(fā)燒友App
PMem 在 2018 年的時(shí)候還僅限于學(xué)術(shù)界的探討，而如今已經(jīng)來(lái)到了工業(yè)界。Intel 在 2019 年 4 月份發(fā)布了第一款 Intel Optane DC Persistent Memory（內(nèi)部產(chǎn)品代號(hào) Apache Pass），可以說是一個(gè)劃時(shí)代的事件。如果你完全沒有聽說過 PMem，那么可以先通過我之前的文章了解一下。
我們先來(lái)看一下實(shí)物的樣子
是的，DIMM 接口，看起來(lái)就像內(nèi)存。所以很多人會(huì)把 Optane PMem 和 Optane SSD 弄混，因?yàn)槎冀?Optane。實(shí)際上 Optane SSD 是 NVMe 接口，走 PCIe 總線。由于接口和總線不同，Optane PMem 和 Optane SSD 的使用方式也完全不同的。
目前單條（因?yàn)殚L(zhǎng)得像內(nèi)存，所以就用“條”來(lái)做量詞了）容量一共有三種選擇：128G、256G、512G，價(jià)格還是相當(dāng)貴的。
這里我想強(qiáng)調(diào)的是：PMem 并不是更慢的內(nèi)存，也不是更快的 SSD，PMem 就是 PMem，他有大量屬于自己的特性。為了使用好 PMem，我們還需要對(duì) PMem 了解更多。
首先，由于 PMem 是 DIMM 接口，可以直接通過 CPU 指令訪問數(shù)據(jù)。讀取 PMem 的時(shí)候，和讀取一個(gè)普通的內(nèi)存地址沒有區(qū)別，CPU Cache 會(huì)做數(shù)據(jù)緩存，所有關(guān)于內(nèi)存相關(guān)的知識(shí)，例如 Cache Line 優(yōu)化，Memory Order 等等在這里都是適用的。而寫入就更復(fù)雜了，除了要理解內(nèi)存相關(guān)的特性以外，還需要理解一個(gè)重要的概念：Power-Fail Protected Domains。這是因?yàn)?，盡管 PMem 設(shè)備本身是非易失的，但是由于有 CPU Cache 和 Memory Controller 的存在，以及 PMem 設(shè)備本身也有緩存，所以當(dāng)設(shè)備掉電時(shí)，Data in-flight 還是會(huì)丟失。
針對(duì)掉電保護(hù)，Intel 提出了 Asynchronous DRAM Refresh（ADR）的概念，負(fù)責(zé)在掉電時(shí)把 Data in-flight 回寫到 PMem 上，保證數(shù)據(jù)持久性。目前 ADR 只能保護(hù) iMC 里的 Write Pending Queue（WPQ）和 PMem 的緩存中的數(shù)據(jù)，但無(wú)法保護(hù) CPU Cache 中的數(shù)據(jù)。在 Intel 下一代的產(chǎn)品中，將推出 Enhanced ADR（eADR），可以進(jìn)一步做到對(duì) CPU Cache 中數(shù)據(jù)的保護(hù)。
由于 ADR 概念的存在，所以簡(jiǎn)單的 MOV 指令并不能保證數(shù)據(jù)持久化，因?yàn)橹噶罱Y(jié)束時(shí)，數(shù)據(jù)很可能還停留在 CPU Cache 中。為了保證數(shù)據(jù)持久化，我們必須調(diào)用 CLFLUSH 指令，保證 CPU Cache Line 里的數(shù)據(jù)寫回到 PMem 中。
然而 CLFLUSH 并不是為 PMem 設(shè)計(jì)的。CLFLUSH 指令一次只能 Flush 一個(gè) Cache Line，且只能串行執(zhí)行，所以執(zhí)行效率非常低。為了解決 CLFLUSH 效率低的問題，Intel 推出了一個(gè)新的指令 CLFLUSHOPT，從字面意思上看就是 CLFLUSH 的優(yōu)化版本。CLFLUSHOPT 和 CLFLUSH 相比，多個(gè) CLFLUSHOPT 指令可以并發(fā)執(zhí)行?？梢源蟠筇岣?Cache Line Flush 的效率。當(dāng)然，CLFLUSHOPT 后面還需要跟隨一個(gè) SFENCE 指令，以保證 Flush 執(zhí)行完成。
和 CLFLUSHOPT 對(duì)應(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)專家更提醒，這是一個(gè) SSE2 里面就添加的指令，并不是一個(gè)新指令）可以做到數(shù)據(jù)寫入的時(shí)候 bypass CPU Cache，這樣就不需要額外的 Flush 操作了。NTSTORE 后面也要跟隨一個(gè) SFENCE 指令，以保證數(shù)據(jù)真正可以到達(dá)持久化區(qū)域。
看起來(lái)很復(fù)雜對(duì)吧，這還只是個(gè)入門呢，在 PMem 上寫程序的復(fù)雜度相當(dāng)之高。Intel 最近出了一本書 “Programming Persistent Memory”，專門介紹如何在 PMem 上進(jìn)行編程，一共有 400 多頁(yè)，有興趣的小伙伴可以讀一讀。
為了簡(jiǎn)化使用 PMem 的復(fù)雜度，Intel 成立了 PMDK 項(xiàng)目，提供了大量的封裝好的接口和數(shù)據(jù)結(jié)構(gòu)，這里我就不一一介紹了。
PMem 發(fā)布以后，不少的機(jī)構(gòu)都對(duì)它的實(shí)際性能做了測(cè)試，因?yàn)楫吘怪按蠹叶际怯脙?nèi)存來(lái)模擬 PMem 的，得到的實(shí)驗(yàn)結(jié)果并不準(zhǔn)確。其中 UCSD 發(fā)表的 “Basic Performance Measurements of the Intel Optane DC Persistent Memory Module” 是比較有代表性的。這篇文章幫我們總結(jié)了 23 個(gè) Observation，其中比較重要的幾點(diǎn)如下：
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ā)針對(duì) PMem 的程序，一定要仔細(xì)理解。
PMem 的好處當(dāng)然很多，延遲低、峰值帶寬高、按字節(jié)訪問，這沒什么好說的，畢竟是 DIMM 接口，價(jià)格也在那里擺著。
這里我想給大家提幾個(gè) PMem 的坑，這可能是很多測(cè)試報(bào)告里面不會(huì)提到的，而是我們親身經(jīng)歷過的，供大家參考：
盡管峰值帶寬高，但單線程吞吐率低，甚至遠(yuǎn)比不上通過 SPDK 訪問 NVMe 設(shè)備。舉例來(lái)說，Intel 曾發(fā)布過一個(gè)報(bào)告，利用 SPDK，在 Block Size 為 4KB 的情況下，單線程可以達(dá)到 10 Million 的 IOPS。而根據(jù)我們測(cè)試的結(jié)果，在 PMem 上，在 Block Size 為 4KB 時(shí)，單線程只能達(dá)到 1 Million 的 IOPS。這是由于目前 PMDK 統(tǒng)一采用同步的方式訪問數(shù)據(jù)，所有內(nèi)存拷貝都由 CPU 來(lái)完成，導(dǎo)致 CPU 成為了性能瓶頸。為了解決這個(gè)問題，我們采用了 DMA 的方式進(jìn)行訪問，極大的提高了單線程訪問的效率。關(guān)于這塊信息，我們將在未來(lái)用單獨(dú)的文章進(jìn)行講解。
另一個(gè)坑就是，跨 NUMA Node 訪問時(shí)，效率受到比較大的影響。在我們的測(cè)試中發(fā)現(xiàn)，跨 NUMA Node 的訪問，單線程只提供不到 1GB/s 的帶寬。所以一定要注意保證數(shù)據(jù)訪問是 Local 的。
關(guān)于 PMem 的使用場(chǎng)景，其實(shí)有很多，例如：
作為容量更大，價(jià)格更便宜的主存，在這種情況下，PMem 實(shí)際上并不 Persitent。這里又有兩種模式：
OS 不感知，由硬件負(fù)責(zé)將 DRAM 作為 Cache，PMem 作為主存
OS 感知，將 PMem 作為一個(gè)獨(dú)立的 memory-only NUMA Node，目前已經(jīng)被 Linux Kernel 支持，Patchset
作為真正的 PMem，提供可持久化存儲(chǔ)能力
關(guān)于 PMem 的其他部分，我們后續(xù)還會(huì)有專門的文章介紹。
順便劇透一下，我們即將在今年上半年發(fā)布的 SMTX ZBS 4.5 版本中，包含了針對(duì) PMem 的大量?jī)?yōu)化工作，和上一個(gè)版本相比，整體延遲可以降低超過 80%~
Distributed Consensus and Consistency
Distributed Consensus 在過去十年已經(jīng)被大家研究的比較透徹了，目前各種 Paxos，Raft 已經(jīng)的實(shí)現(xiàn)已經(jīng)被廣泛應(yīng)用在各種生產(chǎn)環(huán)境了，各種細(xì)節(jié)的優(yōu)化也層出不窮。
如果你想系統(tǒng)性的學(xué)習(xí)一下 Distributed Consensus 的話，那么推薦你看一篇?jiǎng)蚺┦?Heidi Howard 的畢業(yè)論文“Distributed consensus revised”。這篇論文可以說是把過去幾十年大家在 Distributed Consensus 上的工作做了一個(gè)大而全總結(jié)。通過總結(jié)前人的工作，整理出了一個(gè) Distributed Consensus 的模型，并且逐個(gè)調(diào)節(jié)模型中的約束條件，從而遍歷了幾乎所有可能的優(yōu)化算法，可以說是庖丁解牛，非常適合作為 Distributed Consensus 的入門文章。
說到 Distributed Consensus，就離不開 Consistency。Distributed Consensus 是實(shí)現(xiàn) Strong Consistency 的非常經(jīng)典的做法，但是，并不是唯一的做法。
Distributed Consensus 只是手段，Strong Consistency 才是目的。
實(shí)現(xiàn) Strong Consistency 的方法還有很多。在過去一段時(shí)間里面，我認(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，我們先來(lái)簡(jiǎn)單看一下通常 Distributed Consensus 是如何做到 Strong Consistency 的。
我們假設(shè)當(dāng)前計(jì)算端的狀態(tài)是 S0，此時(shí)我們收到了一個(gè)請(qǐng)求，要把狀態(tài)變更為 S1。為了完成這個(gè)變更，存儲(chǔ)端會(huì)發(fā)起了一次 Distributed Consensus。如果成功，則計(jì)算端把狀態(tài)變更為 S1；如果失敗，則狀態(tài)維持在 S0 不變?？梢钥吹酱鎯?chǔ)端向計(jì)算端返回的狀態(tài)只有成功和失敗兩個(gè)狀態(tài)，而實(shí)際上存儲(chǔ)端內(nèi)部會(huì)有更多的狀態(tài)，例如 5 個(gè)節(jié)點(diǎn)里面 3 個(gè)成功了，1 個(gè)失敗了，1 個(gè)超時(shí)了。而這些狀態(tài)都被存儲(chǔ)端屏蔽了，計(jì)算端不感知。這就導(dǎo)致計(jì)算端必須等待存儲(chǔ)端完成 Distributed Consensus 以后，才能繼續(xù)向前推進(jìn)。在正常情況下不會(huì)有問題，但一旦存儲(chǔ)端發(fā)生異常，計(jì)算端必須要等待存儲(chǔ)端完成 Leader Election 或 Membership Change，導(dǎo)致整個(gè)計(jì)算端被阻塞住。
而 Aurora 則打破了這個(gè)屏障。Aurora 的計(jì)算端可以直接向存儲(chǔ)端發(fā)送寫請(qǐng)求，并不要求存儲(chǔ)端節(jié)點(diǎn)之間達(dá)成任何的 Consensus。
典型的 Aurora 實(shí)例包含 6 個(gè)存儲(chǔ)節(jié)點(diǎn)，分散在 3 個(gè) AZ 中。每個(gè)存儲(chǔ)節(jié)點(diǎn)都維護(hù)了 Log 的列表，以及 Segment Complete LSN（SCL），也就是已經(jīng)持久化的 LSN。存儲(chǔ)節(jié)點(diǎn)會(huì)將 SCL 匯報(bào)給計(jì)算節(jié)點(diǎn)。計(jì)算節(jié)點(diǎn)會(huì)在 6 個(gè)節(jié)點(diǎn)中，找出 4 個(gè)最大的 SCL，并將其中最小的值作為 Protection Group Complete LSN（PGCL）。而 PGCL 就是 Aurora 實(shí)例已經(jīng)達(dá)成 Consistency Point。
看上去好像和 Multi-Paxos 也有些相似？是的，但 Aurora 并不要求存儲(chǔ)節(jié)點(diǎn)之間達(dá)成任何的 Consensus，發(fā)生故障的時(shí)候，存儲(chǔ)節(jié)點(diǎn)不需要參與 Leader Election，也不需要等待所有的日志復(fù)制完成。這意味著計(jì)算節(jié)點(diǎn)基本上永遠(yuǎn)不會(huì)被阻塞。
Aurora 的精妙之處在于把 Distributed Consensus 從存儲(chǔ)節(jié)點(diǎn)中抽離出來(lái)了，存儲(chǔ)節(jié)點(diǎn)只是單純的負(fù)責(zé)存儲(chǔ)工作就好了，而 Consensus 由計(jì)算節(jié)點(diǎn)來(lái)完成。那這樣看上去好像又和 PacificA 很相似？是的，我認(rèn)為在整體思路上，Aurora 和 PacificA 是非常相似的。我個(gè)人認(rèn)為 Consensus 和存儲(chǔ)節(jié)點(diǎn)的解耦會(huì)是未來(lái)的一個(gè)趨勢(shì)。
除了 Aurora 以外，Remzi 團(tuán)隊(duì)在 FAST 2020 上的 Best Paper：“Strong and Efficient Consistency with Consistency-Aware Durability”，我認(rèn)為也是非常有意思的一篇文章。
通常來(lái)說，我們?cè)诳紤] Consistency 的時(shí)候，都會(huì)結(jié)合 Durability 一起考慮。需要 Strong Consistency，就會(huì)用 Distributed Consensus，或者其他的 Replication 方式完成一次 Quorum Write，保證了 Strong Consistency 的同時(shí)，也保證了 Durability，代價(jià)就是性能差；如果只需要 Weak Consistency，那么就不需要立刻完成 Quorum Write，只需要寫一個(gè)副本就可以了，然后再異步完成數(shù)據(jù)同步，這樣性能會(huì)很好，但是由于沒有 Quorum Write，也就喪失了 Durability 和 Consistency。所以大家一直以來(lái)的一個(gè)共識(shí)，就是 Strong Consistency 性能差，Weak Consistency 性能好。
那有沒有一種方法既能保證 Strong Consistency，同時(shí)又保證 Performance 呢？Remzi 在這篇論文中提出了 “Consistency-Aware Durability”（CAD）的方法，把 Consistency 和 Durability 解耦，放棄了部分 Durability，來(lái)保證 Strong Consisteny 和 Performance。實(shí)現(xiàn)的方法可以用一句話總結(jié)，就是 Replicate on Read。
在 Strong Consistency 中，有一個(gè)很重要的要求就是 Monotonic Reads，當(dāng)讀到了一個(gè)新版本的數(shù)據(jù)后，再也不會(huì)讀到老版本的數(shù)據(jù)。但換一個(gè)角度思考，如果沒有讀發(fā)生，是不存在什么 Monotonic Reads 的，也就不需要做任何為了為了保證 Consistency 的工作（是不是有點(diǎn)像薛定諤的貓？）。
我們?cè)趯憰r(shí)做 Replication，完全是為了保證 Durability，順便完成了保證 Consistency。如果我們可以犧牲 Durability，那么在寫入時(shí)，我們完全不需要做 Replication，寫單復(fù)本就可以了。我們只需要在需要 Consistency 的時(shí)候（也就是讀的時(shí)候）完成 Consistency 的操作就可以了（也就是 Replication）。所以我把這種方法叫做 Replicate On Read。
如果你的應(yīng)用程序?qū)儆趯懚嘧x少的，那么這種方法就可以避免了大量無(wú)用的 Replication 操作，僅在必要的時(shí)候執(zhí)行 Replication，也就是讀的時(shí)候。這樣既保證了 Strong Consistency，又保證了 Performance。真是不得不佩服 Remzi，把 Consensus，Consistency，Durability 研究的太透徹了。
可能做系統(tǒng)的同學(xué)覺得犧牲 Durability 好像不可接受，但是在類似互聯(lián)網(wǎng)應(yīng)用的場(chǎng)景中，一些臨時(shí)數(shù)據(jù)的 Durability 其實(shí)是不太重要的，而 Consistency 才是影響體驗(yàn)的核心因素。我們以打車舉例，如果你看到司機(jī)距離你的位置一開始是 1 公里，然后忽然又變成了 3 公里，這很可能是后臺(tái)的 NoSQL 數(shù)據(jù)庫(kù)發(fā)生了一次故障切換，而從節(jié)點(diǎn)中保存的數(shù)據(jù)是一個(gè)老數(shù)據(jù)，導(dǎo)致破壞了 Monotonic Reads。而司機(jī)位置這種數(shù)據(jù)是完全沒有必要保證 Durability 的，那么在這種情況下利用比較小的代價(jià)來(lái)保證 Monotonic Reads，將極大地改善用戶的體驗(yàn)，你會(huì)看到司機(jī)和你的距離會(huì)越來(lái)越近，而不是忽遠(yuǎn)忽近。
另外再推薦給大家兩篇論文，一篇是 Raft 作者 John Ousterhout 大神的新作 “Exploiting Commutativity For Practical Fast Replication”，還有一篇是用 Raft 實(shí)現(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
在開始之前，我們首先來(lái)回顧一下計(jì)算機(jī)的發(fā)展歷史。到今天為止，主流的計(jì)算機(jī)都是在馮諾依曼架構(gòu)下發(fā)展的，一切的設(shè)計(jì)都圍繞著 CPU、內(nèi)存進(jìn)行。當(dāng) CPU、內(nèi)存的能力不足時(shí)，就通過總線（Bus），不斷地對(duì)他們的能力進(jìn)行擴(kuò)展，例如磁盤、GPU 等等。隨著 CPU 速度不斷升級(jí)，總線的速度也在不斷地升級(jí)，以匹配 CPU 的運(yùn)算速度。同時(shí)，為了安全高效的完成 CPU 以及外設(shè)之間的通信，產(chǎn)生了例如 DMA、IOMMU 等技術(shù)。而總線受限于物理?xiàng)l件，通常只能進(jìn)行非常短距離的通信，CPU 能直接訪問的所有的設(shè)備都需要集成在主板上，也就是我們今天看到的主機(jī)。
在早期 CPU 的處理能力還非常弱的時(shí)候，單個(gè) CPU 無(wú)法勝任大規(guī)模計(jì)算任務(wù)。這個(gè)時(shí)候出現(xiàn)了兩種發(fā)展的流派，一種是 Shared Memory，也就是在單機(jī)內(nèi)擴(kuò)展 CPU 的數(shù)量，所有 CPU 都共享相同的內(nèi)存地址空間；另一種是 Distributed Memory，也可以理解為多機(jī)，每臺(tái)機(jī)器的 CPU 有獨(dú)立的內(nèi)存和獨(dú)立的地址空間，程序之間通過 Message-Passing 的方式進(jìn)行通信。Shared Memory 技術(shù)對(duì)于硬件的要求較高，需要在處理器之間實(shí)現(xiàn) Cache Coherence，而軟件層面的改動(dòng)較為容易，早期的典型代表就是 Mainframe Computer，也就是俗稱的大型機(jī)；而 Distributed Memory 則對(duì)硬件的要求較低，但是軟件需要采用 Message-Passing 的方式進(jìn)行重寫，例如早年的 MPI 類的程序，主要應(yīng)用在 HPC 領(lǐng)域。由于 Mainframe 的硬件成本太高，MPI 逐漸成為了主流。
在上世紀(jì)八九十年代的時(shí)候，曾經(jīng)流行了一陣 Distributed Shared Memory（DSM）技術(shù)，也就是分布式共享內(nèi)存。DSM 通過操作系統(tǒng)的內(nèi)存管理系統(tǒng)把各個(gè)獨(dú)立服務(wù)器上的內(nèi)存地址連接到一起，組成連續(xù)的內(nèi)存地址，使得應(yīng)用程序可以更方便的做數(shù)據(jù)共享。但 DSM 技術(shù)一直沒有發(fā)展起來(lái)，主要是受限于不斷提升的 CPU 頻率和當(dāng)時(shí)的網(wǎng)絡(luò)速度越來(lái)越不匹配，導(dǎo)致 DSM 的通信成本過高，無(wú)法被普及。
到了 2000 年以后，CPU 的發(fā)展逐漸遇到瓶頸，單核計(jì)算性能已經(jīng)不再可能有大的突破，CPU 逐漸轉(zhuǎn)向多核方向發(fā)展，個(gè)人電腦也用上了 Shared Memory 技術(shù)。而隨著大數(shù)據(jù)對(duì)算力和存儲(chǔ)能力的要求，Distributed Memory 技術(shù)也越來(lái)越廣泛地被使用，例如 MapReduce 和 Spark 這種計(jì)算框架就是典型的代表。
到了最近幾年，CPU 速度依然沒有明顯的突破，但網(wǎng)絡(luò)速度卻在發(fā)生翻天覆地的變化。包括 IB 和以太網(wǎng)都可以達(dá)到 200Gb 的帶寬和 us 級(jí)別的延遲（據(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 還包括了對(duì)存儲(chǔ)的討論。在論文中，作者把 CPU、Memory 和 Storage 分別抽象為 pComponent、mComponent 和 sComponent，這些設(shè)備之間通過 RDMA 網(wǎng)絡(luò)連接在一起。LegoOS 向用戶提供了 vNode 的概念，每個(gè) vNode 類似一個(gè)虛擬機(jī)，可以包含一個(gè)或多個(gè) pComponent，mComponent 和 sComponent。而每個(gè) Component 同時(shí)也可以服務(wù)于多個(gè) vNode。LegoOS 會(huì)負(fù)責(zé)對(duì)資源的隔離。由于具有統(tǒng)一的內(nèi)存地址空間，且兼容 POSIX 接口，應(yīng)用程序不需要被改寫就可以運(yùn)行在 LegoOS 上。
LegoOS 是一個(gè)非常不錯(cuò)的想法，但我認(rèn)為在實(shí)現(xiàn)上會(huì)面臨著非常巨大的挑戰(zhàn)，一方面由于大部分的功能都需要依賴軟件來(lái)實(shí)現(xiàn)，延遲可能會(huì)受到一定的影響，另一方面是 LegoOS 沒有采用 Cache Coherence 的模型，而是用了 Message-Passing 的方式在各個(gè) Component 之間進(jìn)行通信。Message-Passing 可能是更優(yōu)雅設(shè)計(jì)方案，但是如果真的想要在工業(yè)界中實(shí)現(xiàn) LegoOS 這種思想，硬件廠商有需要根據(jù) Message-Passing 來(lái)重新設(shè)計(jì) Driver，這對(duì)于已有的硬件生態(tài)來(lái)說恐怕是很難接受的。
在工業(yè)界中，盡管目前還沒有看到 DSM 的成功案例，但是目前已經(jīng)開始看到一些相關(guān)的技術(shù)出現(xiàn)。這里我們會(huì)重點(diǎn)關(guān)注一下總線（Bus）技術(shù)。
最近幾年，異構(gòu)計(jì)算（heterogeneous computing）變得越來(lái)越常見，CPU 通過 PCIe 總線和 GPU、FPGA 等異構(gòu)計(jì)算單元進(jìn)行通訊。而由于 PCIe 總線誕生時(shí)間較早，不支持 Cache Coherence，所以為編寫異構(gòu)計(jì)算的應(yīng)用程序帶來(lái)了極大的復(fù)雜度。例如應(yīng)用程序想要在 CPU 和 GPU 之間共享數(shù)據(jù)，或者 GPU 和 GPU 之間共享數(shù)據(jù)，必須自行處理可能產(chǎn)生的 Cache 一致性問題。
為了適應(yīng)逐漸增加的異構(gòu)計(jì)算場(chǎng)景，各個(gè)廠商開始籌劃推出新的總線技術(shù)，這包括：
來(lái)自 Intel 的 Compute Express Link（CXL）
來(lái)自 IBM 的 Coherent Accelerator Interface（CAPI）
來(lái)自 Xilinx 的 Cache Coherence Interconnect for Accelerator（CCIX）
來(lái)自 AMD 的 Infinity Fabric
來(lái)自 NVIDIA 的 NVLink
毫無(wú)例外，不同廠家的技術(shù)都提供了對(duì) Cache Coherence 的支持，這正是 PCIe 總線所缺乏的，也是工業(yè)界所需要的。目前這場(chǎng)關(guān)于下一代總線的競(jìng)爭(zhēng)還在進(jìn)行中，但大家認(rèn)為能笑到最后的恐怕還是 Intel 所支持的 CXL。
這里我們只對(duì) CXL 做一個(gè)簡(jiǎn)單的介紹。
CXL 協(xié)議中定義了 3 種子協(xié)議：
http://CXL.io：不提供 Cache Coherence 的 IO 訪問，類似于目前的 PCIe 協(xié)議
CXL.cache：用于設(shè)備訪問主存
CXL.memory：用于 CPU 訪問設(shè)備內(nèi)存
例如對(duì)于一個(gè) GPU 設(shè)備，可以通過 CXL 來(lái)進(jìn)行 GPU 到 CPU，GPU 到 GPU 的數(shù)據(jù)交換。而由于 CXL 支持 Cache Coherence，這個(gè)過程將變得非常簡(jiǎn)單，這無(wú)疑是一個(gè)重大的變化。而對(duì)于存儲(chǔ)設(shè)備來(lái)說，CXL 使得 PMem 無(wú)論是作為持久化內(nèi)存還是易失性內(nèi)存，都可以不僅僅局限在內(nèi)存總線，而是可以通過 CXL.memory 和 CPU 進(jìn)行通信。這意味著 PMem 未來(lái)不僅僅可以提供類似目前 NVMe 設(shè)備的熱插拔功能，還可以擺脫內(nèi)存總線對(duì)散熱和功耗的限制。甚至更進(jìn)一步，未來(lái)可能會(huì)出現(xiàn) CXL over Fabric 的技術(shù)，CPU 可以通過 CXL 協(xié)議訪問遠(yuǎn)端內(nèi)存。
CXL 1.0 將采用和 PCIe Gen5 向兼容的硬件標(biāo)準(zhǔn)，這樣一來(lái)硬件廠商不需要為適配不同協(xié)議而生產(chǎn)兩種不同接口的硬件設(shè)備，統(tǒng)一采用 PCIe Gen5 的標(biāo)準(zhǔn)就可以了。如果在設(shè)備協(xié)商階段發(fā)現(xiàn)對(duì)端支持 CXL 協(xié)議，那么就可以采用 CXL 協(xié)議運(yùn)行，否則可以采用 PCIe Gen5 運(yùn)行。
CXL.cache 和 CXL.memory 組成了一個(gè)異構(gòu)的 Shared Memory 系統(tǒng)，這對(duì)傳統(tǒng)的 Shared Memory 系統(tǒng)是一個(gè)極大的擴(kuò)展，讓異構(gòu)計(jì)算變得更加簡(jiǎn)單。而 CXL over Fabric 可能會(huì)組成一個(gè)由硬件支持的 Distributed Shared Memory 系統(tǒng)，這將使 Memory-level Composable Infrastructure 成為可能。在未來(lái)的數(shù)據(jù)中心，很可能會(huì)出現(xiàn)專門用于池化內(nèi)存的服務(wù)器，CPU、內(nèi)存像樂高一樣搭建起來(lái)將真正成為現(xiàn)實(shí)。而這一切都有可能在未來(lái)的 5~10 年內(nèi)發(fā)生。
其他方面
Open-Channel SSD
Open-Channel SSD 我在之前的文章中也做過介紹。和兩年前相比，目前已經(jīng)被很多云廠商用起來(lái)了。相比于傳統(tǒng) SSD，采用 Open-Channel SSD 的好處是可以定制 FTL，從而方便對(duì)特定的 Workload 進(jìn)行優(yōu)化。但 Open-Channel SSD 短期內(nèi)恐怕只會(huì)被云廠商采用，畢竟大部分用戶沒有定制 FTL 的需求，通用的 FTL 就已經(jīng)足夠了。而隨著 SPDK 中加入了對(duì) FTL 的支持，也許未來(lái)會(huì)有廠商選擇直接在用戶態(tài)運(yùn)行 Open-Channel SSD。
LSM-Tree 優(yōu)化
過去兩年這方面的進(jìn)展也比較少，我看過唯一相關(guān)的論文，是在 FAST ’19 上的一篇論文：SLM-DB： Single-Level Key-Value Store with Persistent Memory，對(duì) PMem 上運(yùn)行 LSM-Tree 進(jìn)行優(yōu)化。目前隨著 IO 設(shè)備的速度越來(lái)越快，大家都比較認(rèn)可 LSM-Tree 已經(jīng)從 IO Bound 轉(zhuǎn)移到 CPU Bound，LSM-Tree 的劣勢(shì)越來(lái)越明顯，這讓大家開始反思是否應(yīng)該繼續(xù)使用 LSM-Tree 了。
Machine Learning and Systems
盡管兩年前開始有 Machine Learning For Systems 的相關(guān)工作，但是過去兩年一直沒有什么實(shí)質(zhì)性的進(jìn)展，反倒是 Systems for Machine Learning 有一些和 GPU 任務(wù)調(diào)度相關(guān)的工作。
VirtIO without Virt
VirtIO 是專門為虛擬化場(chǎng)景設(shè)計(jì)的協(xié)議框架。在 VirtIO 框架下，可以支持各種不同設(shè)備的虛擬化，包括 VirtIO-SCSI，VirtIO-BLK，VirtIO-NVMe，VirtIO-net，VirtIO-GPU，VirtIO-FS，VirtIO-VSock 等等。而 VirtIO 設(shè)備虛擬化的功能一直都是由軟件來(lái)完成的，之前主要是在 Qemu 里面，現(xiàn)在還有 VHost。而目前逐漸有硬件廠商開始嘗試原生支持 VirtIO 協(xié)議，把虛擬化的功能 Offload 到硬件上完成，這樣進(jìn)一步降低 Host 上因虛擬化而產(chǎn)生的額外開銷。這也是 AWS Nitro 的核心技術(shù)之一，通過把 VirtIO Offload 給硬件，使得 Host 上的幾乎所有 CPU、內(nèi)存資源都可以用于虛擬機(jī)，極大的降低了運(yùn)營(yíng)成本。
Linux Kernel
目前 Linux Kernel 已經(jīng)來(lái)到了 5.0 的時(shí)代，近期比較重要的一個(gè)工作就是 IO_URING。關(guān)于 IO_URING，我們之前在文章中也做過介紹。IO_URING 和一年前相比又有了巨大的進(jìn)步，目前除了支持 VFS 以外，也已經(jīng)支持 Socket，為了提高性能還專門寫了新的 Work Queue。IO_URING 的終極目標(biāo)是 one system call to rule them all，讓一切系統(tǒng)調(diào)用變成異步！
工商網(wǎng)監(jiān)
評(píng)論