動機和背景

存儲計算&IO棧

存儲計算可以降低數(shù)據(jù)移動開銷并充分利用設備內(nèi)帶寬，相比于特定計算加速，通用存儲計算框架可以允許用戶自定義卸載到存儲設備的計算邏輯。然而大部分工作都關(guān)注于控制存儲設備的接口和用戶空間，但是缺乏對主機側(cè)計算&存儲資源的充分利用。IO棧是管理存儲器的的基本組件，包括設備驅(qū)動、塊接口層、文件系統(tǒng)，目前一些用戶空間IO庫（如SPDK）有效降低了延遲，但是io棧仍然不可或缺。這是因為1）大部分引用采用POSIX接口需要IO棧的兼容性；2）IO棧提供了包括page cache、文件系統(tǒng)等多種功能模塊。而用戶空間IO庫只提供原始數(shù)據(jù)傳輸功能；3）IO?？梢允沟貌煌脩簟贸浞止蚕泶鎯υO備。

主機-設備協(xié)作

作者通過測試，發(fā)現(xiàn)不同特征的應用，對主機/設備具有不同的適應性。例如，在主機/設備側(cè)分別運行Stat64和stat32。stat64在主機側(cè)運行更快，stat32在設備側(cè)運行更快。另外，一個應用的不同運行階段，也具有不同的特征。例如使用warm page-cache策略運行stat64，發(fā)現(xiàn)無緩存時在設備上更快，緩存越多主機端越快。

eBPF

eBPF是一種內(nèi)核中的虛擬機，允許用戶在不修改內(nèi)核源碼的情況下運行一段代碼，其運行過程如下圖所示。因為eBPF可以提供硬件無關(guān)的字節(jié)碼格式，其可用于構(gòu)建ISC運行時。然而，eBPF也存在一些問題：1）eBPF的靜態(tài)校驗器過于嚴格；2)缺乏指針訪問和動態(tài)長度循環(huán)機制。因此，需要對eBPF進行擴展以更好的支持存儲計算。

設計方案

λ-IO通過擴展vanilla-IO框架，支持將計算動態(tài)卸載到內(nèi)核/設備中進行計算。

它由三部分組成，如下圖所示：

λ-IO API：用于提供擴展的應用編程接口

λ運行時：包括λ內(nèi)核運行時和λ設備運行時，用于提供λ請求的計算接口

請求分發(fā)器：用于評估效率，將任務自動分發(fā)給設備/內(nèi)核執(zhí)行。

λ-API

λ-API繼承了vanilla IO的open/close/read/write接口，并擴展了λ_load/ λ _read/λ_write接口用于應用提交計算卸載請求。其中，λ函數(shù)是計算方法的實體，load_ λ用于將λ函數(shù)編譯為eBPF代碼；而open_λ/close_ λ：與vanilla中的定義保持一致，可以使用vanilla/ λ擴展函數(shù)。

pread_λ和pwrite_λ用于執(zhí)行計算卸載，其中pread_λ表示以fd,offset,length表示的文件內(nèi)容作為入?yún)?zhí)行λ_id表示的λ函數(shù)，并將返回結(jié)果寫到buf中。其執(zhí)行步驟為：1）將文件數(shù)據(jù)作為輸入數(shù)據(jù)加載到內(nèi)存buffer中；2）為輸出數(shù)據(jù)分配buffer空間；3）執(zhí)行λ函數(shù)；4）將輸出buffer的數(shù)據(jù)拷貝到用戶分配的buffer中。pwrite_λ與pread_λ類似，但是其輸入、輸出參數(shù)相反。

λ運行時

λ運行時是執(zhí)行l(wèi)oad_ λ, pread_ λ, pwrite _λ的核心，它的實現(xiàn)具有兩方面的關(guān)鍵挑戰(zhàn)：1）計算：內(nèi)核/設備的λ運行時都需要保存、執(zhí)行計算函數(shù)；2）數(shù)據(jù)：λ運行時需要保存、訪問文件數(shù)據(jù)和用戶應用信息。

作者通過允許sBPF對BPF代碼執(zhí)行動態(tài)驗證，使能指針、循環(huán)將eBPF擴展為sBPF。其中，指針訪問的修改包括在JIT中增加指針地址檢測代碼，讓sBPF可以在運行中檢查指針，若指針未落在輸入buffer中，則停止執(zhí)行并返回錯誤碼。另外，作者表示，所有循環(huán)都包括一個offset為負的跳轉(zhuǎn)指令，因此sBPF使用了一個動態(tài)的后跳計數(shù)器，并限制后跳的執(zhí)行次數(shù)，以避免死循環(huán)的發(fā)生。作者之后對其安全性進行了分析，并表示雖然增加了功能，但由于檢驗嚴格，并不會增加eBPF的安全性風險。

關(guān)于數(shù)據(jù)問題，主要是設備/內(nèi)核的一致性訪問問題。對于λ內(nèi)核運行時，作者使用內(nèi)核中通用的kernel_write和kernel_read訪問文件，讓內(nèi)核管理頁緩存和文件一致性，另外為了減少讀寫文件引起的大規(guī)模內(nèi)存搬移，作者提出kernel_mmap進行內(nèi)存映射解決這個問題。

對于設備運行時的文件一致性訪問，作者提出，雖然由于設備對文件語義不可知，需要準確的物理地址，但是文件的IOCTL中由FIEMAP和FIBMAP用于提取元數(shù)據(jù)中的物理地址，可以解決設備的文件訪問問題。而一致性問題包括內(nèi)核-用戶空間一致性和主機-設備一致性兩方面，對于內(nèi)核-用戶空間一致性問題，由于采用的是標準syscall接口，內(nèi)核可以管理一致性，而主機設備一致性問題則通過1）使用讀寫鎖避免同時訪問帶來的一致性風險；2）在分發(fā)λ請求前，將請求數(shù)據(jù)文件相關(guān)的臟頁刷入設備并清空緩存，可以解決其一致性問題。

請求分發(fā)器

請求分發(fā)器的目的是通過預測主機、設備對某個任務的執(zhí)行時間，選擇其中更快的那個進行分發(fā)，以達到更快、更高效的目的。為了評估執(zhí)行時間，需要對執(zhí)行時間進行建模。

為此，首先對相關(guān)變量進行符號表示如下表。

之后，對主機、設備端分別建模其執(zhí)行時間，當不考慮緩存時，使用pread_λ在內(nèi)核、設備端的執(zhí)行時間如下公式所示

。當考慮緩存時，則其形式變?yōu)槿缦?/p>

。而pwrite_λ的執(zhí)行時間則為

。

評估

評估環(huán)境

本文中在一個配備4核8線程的I7-7700@3.6GHz，16GB DDR4內(nèi)存的電腦上運行內(nèi)核為linux 5.10.21的Ubuntu20.04LTS操作系統(tǒng)進行測試。存儲計算設備則采用Xilinx Zynq Ultrascale+ ZU17EG搭配2GB內(nèi)存核64GBNand Flash。測試負載包括Stat64, Stat32, KNN, Grep, Bitmap。評估對比對象包括了1）Buffer IO(B):默認的vanilla IO；2）DirectIO(I):類似Buffer IO，但開啟O_DIRECT；3）Mmap(M):將數(shù)據(jù)文件讀入用戶空間，避免內(nèi)核數(shù)據(jù)拷貝；4）λ-IO kernel(K):使用內(nèi)核計算的λ-IO；5）λ-IO device(D):使用設備計算的λ-IO；6）λ-IO(λ):啟用請求分發(fā)的λ-IO。

單應用性能測試

對單個應用的性能分析，作者將執(zhí)行時間細分為三部分:IO/計算/其他。首先對比λ-IO Device(d)和Buffer IO(B)。可以發(fā)現(xiàn)，d相比B,Stats64, KNN, Grep, Bitmap分別提升23.24%, 10.82%, 87.13%, 60.15%。這是由于主機端IO時間占比超過92.04%。另外，由于設備僅有4核4線程，而主機發(fā)送請求為8線程，因此出現(xiàn)了請求排隊現(xiàn)象。在stat32中d執(zhí)行時間超過B 6.65倍 ，是由于64位eBPF對32位程序執(zhí)行效率不高導致的。

之后作者對比了λ-Io Kernel(k)核vanilla-IO(B)之間的性能差異，并發(fā)現(xiàn)二者性能基本相同。λ-IO由于sBPF增加了運行時動態(tài)檢驗，帶來了部分額外開銷，但是又因為kernel_mmap避免了內(nèi)存復制的開銷，二者基本相互抵消。

最后作者對比了λ-IO不同模式之間的性能差異，并發(fā)現(xiàn)，引入請求分配器的λ-IO在每項測試中的性能都基本相當于k、d模式下更快的那一個，并且通過對比，可以發(fā)現(xiàn)請求分配器帶來的額外開銷約為4.98%。

多應用評估

作者通過同時運行5種負載之二評估同時運行不同負載的性能差別。發(fā)現(xiàn)，當運行項包括stat32時，Stat32被分發(fā)到主機，另一個分發(fā)到設備運行，因此λ-IO性能提升2.19倍，其他情況下λ-IO也有1.98倍的整體性能提升。

敏感性分析

作者接著進行了敏感性分析。首先是數(shù)據(jù)集大小敏感性，作者使用stat64測試為例，發(fā)現(xiàn)在緩存>數(shù)據(jù)集大小時，由于避免了IO瓶頸，內(nèi)核性能最佳，當緩存≈數(shù)據(jù)大小時，頁緩存的影響變小，λ-IO性能更好，當數(shù)據(jù)>緩存大小時，λ-IO由于高效分發(fā)請求，比其他對照組快1.28-1.60倍不等。

接著是熱啟動敏感性，作者發(fā)現(xiàn)Buffer-IO在熱啟動下性能比冷啟動更好一些，但是λ-IO性能仍是Buffer-IO的4.05倍。

之后作者分析了請求分發(fā)器的預測周期和預測長度的敏感性，發(fā)現(xiàn)，當預測周期超過200后，性能基本不發(fā)生改變，因此將默認預測周期設為200，而對于預測長度，可以看到隨著預測長度增加，執(zhí)行時間迅速增長，因此默認預測長度被設為5。

對于緩存大小和線程數(shù)量，可以看到大部分應用對緩存大小不敏感，且大部分應用隨著線程數(shù)增長而增長，并在4線程時基本觸頂。

BPF開銷

通過對比運行時間，作者表示sBPF相比eBPF，循環(huán)檢查對內(nèi)核/設備增加不超過2.44%和10.09%的開銷，加上指針檢查，sBPF對內(nèi)核/設備引入不超過16.96%和22.68%的額外開銷。

Spark SQL

作者最后將spark SQL移植適配λ-IO，并測試了其在TPC-H負載下的真實性能表現(xiàn)。對比發(fā)現(xiàn)在buffer-IO模式下，IO占用了27.02%-60.41%的總時間，λ-IO Kernel與buffer-IO類似，λ-IO將任務分發(fā)至設備，提升最高81.55%的性能，暖啟動后λ-IO比B/K/D分別提升2.15、2.16、1.51倍，在CPU密集型任務中Q20任務在D中執(zhí)行時間比K少18.45%。

總結(jié)

在本文中提出了λ-IO，其擴展了Linux IO，使計算能夠卸載到主機內(nèi)核和設備。作者在真實的軟硬件環(huán)境中實現(xiàn)并評估了λ-IO，其顯示出顯著的性能提升。