原文作者：charlieroro
原文鏈接：https://www.cnblogs.com/charlieroro/p/14666082.html
譯自：BPF for storage: an exokernel-inspired approach
BPF主要用于報文處理，通過繞過網絡棧提高報文的處理速度。本文則用于通過繞過存儲棧(文件系統、BIO等層)來提高存儲的讀寫效率，但在實現過程中也遇到了相應的挑戰，如文件和塊的映射關系，多進程共享存儲塊以及進程間的QoS等。
概要
內核存儲路徑開銷占新式NVMe存儲設備訪問延遲的一半。本文中我們將探究使用BPF在內核的I/O處理棧中注入用戶定自定義函數來降低這種開銷。當發起一系列獨立的I/O請求時，這種方式可以(通過繞過內核層以及避免跨內核邊界)增加2.5倍的IPOS，并降低一半延遲。但在繞過文件系統和塊設備層的同時時應該避免丟失重要的屬性，如文件系統的安全性和物理塊地址和文件偏移之間的轉換。我們從90年代后期的外核文件系統中汲取靈感，為這些問題提供了可能的解決方案。
簡介
歷史上，存儲設備在實現高帶寬和低延遲的目標上要遠低于網絡設備，現在很多網卡(NICs)都可以支持100 Gb/s的帶寬，而物理層的存儲設備僅支持2-7GB/s的帶寬，以及4-5us的延遲[8, 13, 19, 20]。當使用這些存儲設備時，軟件棧會在每個存儲請求上花費大量開銷，在我們的實驗中占存儲請求占了一半的I/O操作延遲，且可能對吞吐量造成更大的影響。
內核旁路(kernel -bypass)框架(如SPDK[44])以及靠近存儲的處理方式可以降低內核開銷。但兩者同樣都有明顯的缺點，例如通常需要定制，需要對應用程序進行更改[40，41]，缺乏隔離性，在I/O使用率不高時會浪費大量等待時間，以及在計算存儲中需要定制的硬件[10, 16, 42]。因此，我們期望使用一個支持標準OS的機制來降低高速存儲設備的軟件開銷。
為此，我們參考了很早就支持高速帶寬設備的網絡通信。Linux的eBPF[6]為應用提供了一種直接在內核中嵌入簡單函數的接口。當用于攔截I/O時，可以在應用中使用這些函數進行處理，以此來避免內核和用戶空間的上下文切換和數據拷貝。Linux eBPF通常用于報文處理和過濾[5,30]、安全[9]和追蹤[29]。
BPF在內核中普遍存在，并被廣泛用于在網絡棧外針對特定應用進行內核側擴展。BPF可以用于鏈式依賴的I/Os，消除內核存儲棧傳輸以及與用戶空間的數據轉換造成的開銷。例如，它可以遍歷一個基于磁盤的數據結構(B樹，該數據結構中一個塊會引用另一個塊)。通過在內核中嵌入這些BPF函數，就可以像內核旁路一樣消除發起I/Os造成的開銷，但與內核旁路不同的是，它不需要輪詢以及浪費CPU時間。
為了了解BPF可以獲得的性能，我們確立了四個與存儲使用有關的開放研究。首先，為了便于采納研究結果，在架構上必須支持標準的Linux文件系統，并盡量減少對應用的修改，同時應該兼具靈活性，且能夠高效運行并繞過大量軟件層；其次，存儲使BPF超出了當前的簡單報文處理的范疇，由于報文是自描述的，這使得BPF對它們的處理在大部分場景下是相互隔離的。而硬盤上的數據結構的傳輸通常是有狀態的，且經常需要查詢外部狀態。存儲BPF需要了解應用的磁盤格式，并訪問外部的應用狀態或內核狀態。例如，為了并發訪問或訪問內存的結構的元數據；再者，我們需要保證BPF存儲函數在允許應用間共享磁盤容量時不會違背文件系統的安全性。存儲塊本身通常不會記錄塊的所有者或訪問控制屬性，與網絡報文相比，報文的首部指定了該報文所屬的流。因此我們需要一種有效的方案來實施訪問控制，且不會在內核文件系統和塊層引入開銷。最后，我們需要保證并發性。應用程序需要通過細粒度同步(如鎖耦合[28])來支持并發訪問，以此避免讀寫對高吞吐量的影響，因此BPF函數可能需要同步功能。
我們的靈感來源于外核文件系統。用戶定義的內核擴展是XN的基石(用于Xok 外核)，它通過從用戶進程下載到內核[32]的代碼來支持互不信任的"libfs"es。在XN中，這些不可信的功能被解釋為讓內核按照用戶定義的方式來理解文件系統元數據。這種方式不會影響應用和內核設計，且滿足了文件系統布局的靈活性目標。雖然我們需要一個類似的機制來允許用戶讓內核理解他們的數據布局，但實現的目標是不同的：我們希望在設計上允許應用使用自定義的兼容BPF的數據結構以及傳輸和過濾磁盤數據的功能，且能夠與Linux現有的接口和文件系統一起運作，通過大幅削減每個I/O執行所需要的內核代碼量來驅動百萬級的IOPS。
軟件是存儲的瓶頸
在過去的幾年中，使用NVMe連接到高帶寬PCIe的SSD中出現了新的內存技術，這使得存儲設備在性能上可以與高速網絡設備[1]相媲美，具有毫秒級的訪問延遲以及每秒GB級別的帶寬[8, 13, 19, 20]。現在內核存儲棧成為了這些新式設備的瓶頸。
圖1展示了這種情況，可以看到硬件的I/O的延遲比例降低了，由于設備硬件和系統軟件的增長，使得存儲設備的速度越來越快。從下圖中可以看到，在第一代NVMe設備中已經可以觀測到軟件帶來的開銷(10-15%延遲開銷)。在新一代設備中，軟件開銷則占到了幾乎一半的讀I/O延遲。
圖1：使用512B隨機讀下的內核延遲開銷。HDD為Seagate Exos X16, NAND為 Intel Optane 750 TLC NAND, NVM-1是第一代Intel Optane SSD (900P), NVM-2是第二代Intel Optane SSD (P5800X)
開銷源。為了降低軟件開銷，我們需要通過發起隨機512B read()調用(設置O_DIRECT選項)來測量不同軟件層的平均延遲，測試環境為Intel Optane SSD Gen 2 prototype (P5800X)，6核i5-8500 3GHz，16GB內存，系統為Ubuntu20.04，內核Linux 5.8.0。本文使用的都是該配置。我們僅用了處理器的C-states和睿頻加速技術，并使用最大性能調節器。表1展示了耗時最多的為文件系統層(此處為ext4)，隨后是用戶空間和內核空間之間的轉換。
表1：使用第二代Intel Optane SSD測試512B隨機read()調用的平均延遲
內核旁路允許應用直接將請求提交到設備，有效消除了除給NVMe提交請求以及設備本身造成的延時[22, 33, 44, 45]之外的開銷。但消除這些層的代價也比較高昂。內核只能將任務委派給整個設備進行處理，此時必須在裸設備[40, 41]上實現應用自己的文件系統。但即使這么做，也無法保證不可信進程之間的文件和容量共享的安全性。最終，由于缺少有效的應用層中斷派發，意味著應用必須采用輪詢來保證高負載，最終導致無法有效地在多個進程間共享核，而在頻繁輪詢時也會造成I/O浪費。
最近采用了一種稱為io_uring[7]的系統調用來優化I/O提交造成的開銷。它使用批量和異步I/O submission/completion路徑(參見圖2)來分攤跨內核造成的開銷，并且避免使用調度器交互來阻塞內核線程。但每個提交的I/O仍然會經過所有的內核層(如表1所示)，因此，在訪問高速存儲設備時，每個I/O仍然會造成大量軟件開銷(見下文)。
BPF是解藥？
隨著高速網絡的崛起，為Berkeley Packet Filter(BPF)帶來了新的機會，由于不需要將報文拷貝到用戶空間，因此可以高效地處理報文，同時應用也可以安全地在內核中對報文進行操作。一般的網絡場景包括報文過濾[4,5,21,30]，網絡跟蹤[2,3,29]，負載均衡[4,12]，報文引導[27]以及網絡安全檢查[9]等。BPF也被用作一種在訪問分類存儲時避免多網絡交叉的方法[35]。可以使用解釋器或JIT編譯器來運行用戶定義的函數。
存儲使用BPF。可以預見，在發起獨立的存儲請求時，可以使用BPF來移除內核存儲棧以及內核空間和用戶空間之間的數據交互。很多存儲應用包含很多"輔助"I/O請求，如索引查詢。這些請求最主要的一個特點是它們會占用I/O帶寬以及CPU時間來獲取永遠不會返回給用戶的數據。例如，對一個B樹索引的查找其實是一系列指針查找，用來生成對用戶數據頁的最終I/O請求。每個查找都會經應用到內核存儲棧，僅僅是為了在應用簡單處理之后丟棄數據。其他類似的場景包括數據庫迭代器，它會順序掃描表，直到某個屬性滿足條件[15]，或圖數據庫執行深度優先查找[24]。
好處。我們設計了一個在使用B+樹(索引數據庫的常用數據結構)的磁盤上執行查找的性能測試。為了簡化，實驗會假設索引的葉子包含用戶數據(而非指針[36])。我們假設B樹的每個節點都位于獨立的磁盤頁，意味著對于一顆深度為d的B樹，需要從磁盤讀取d個頁。B樹查找的核心操作是通過解析當前頁來找出下一個磁盤頁的偏移量，并對下一頁發起讀操作，即"指針查找"。傳統上，一個B樹查找需要在用戶空間連續執行d個指針查找。為了提高基準，我們從內核堆棧中的兩個鉤子之一重新發出連續的指針查找：系統調用派發層(主要消除跨內核開銷)或completion路徑上的NVMe驅動中斷處理器。圖2顯示了兩個鉤子的派發路徑以及正常的用戶空間派發路徑。這兩個鉤子用來代理eBPF鉤子，我們最終將使用它們來完成用戶定義的功能。
圖2：應用的派發路徑和兩個內核鉤子
圖3a和圖3b展示了兩個與基準應用遍歷有關的鉤子的吞吐量增量。圖3c展示了B樹的深度對兩個鉤子的延遲的影響。當從系統調用派發層發起查找時，最大可以提升1.25倍。由于每次查找仍然會存在文件系統和塊層的開銷，因此提升并不明顯。提升完全來自于消除跨內核帶來的開銷。存儲設備的延遲接近1us，我們希望從派發鉤子上獲得更大的提升。另一方面，通過繞過幾乎整個軟件棧，從NVMe驅動程序重新發出的命令可大大減少后續I/O請求的計算量，這種方式可以提升2.5倍速度，并減少49%的延遲。但當添加更多的線程時，反而降低了相對吞吐量的提升，這是因為在達到CPU飽和之前(線程數為6)，基準應用也會從中(增加線程)受益。一旦基準達到CPU飽和之后，由重新分配驅動程序而節省的計算量會變得更加明顯。由于樹的每一級都包含了可以廉價發起的請求，因此吞吐量的提高將隨著樹的深度而不斷擴大。
圖3：從不同的內核層發起查找時，B樹深度和吞吐量的關系
圖3a：使用read系統調用查找，使用系統調用層鉤子(可以看到線程對性能的提升并不大)
圖3b：使用read系統調用查找，使用NVMe驅動層鉤子(由于繞過了BIO和文件系統層，因此性能提升明顯)
圖3c：使用read系統調用單線程查找，使用系統調用層和NVMe驅動層鉤子
圖3d：使用io_uring系統調用單線程查找，使用NVMe驅動鉤子(B樹深度越深，可節省的I/O計算就越多)
io_uring怎么樣？前面實驗中使用了Linux標準的同步read系統調用。這里我們使用更高效、批量化的io_uring submission路徑來重復這些測試場景，使用單線程來驅動B樹查找。像之前一樣，我們在NVMe驅動中重新發起查詢請求，使用未修改的io_uring調用執行批量I/O，并繪制吞吐量提升圖。圖3d展示了在驅動中發起查找后的(相對于應用基準的)吞吐量提升。
如預期的一樣，增加批處理調用的數目(在每個io_uring調用中的系統調用的數目)會提升吞吐量，這是因為更高的批處理會增加驅動發起的請求的數目。例如，可以廉價地發起只有一個請求(B樹的每一層)的批處理，而對于大小為8的批處理，B樹的每一層會節省8個并發請求。因此將鉤子靠近設備有利于標準的同步read調用，并使得io_uring調用更加高效。使用深度樹時，BPF與io_uring結合使用可將吞吐量提高2.5倍以上；且三個相關的查找也可以實現1.3–1.5倍的提升。
設計存儲BPF
上述實驗已經告訴我們使用BPF優化高速存儲設備操作速度的原因。但為了達到這些目標，需要盡早執行I/O重提交，理想情況是在內核的NVMe中斷處理器內部提交I/O。但這也為使用BPF查找如鍵-值存儲這樣的實用系統帶來巨大挑戰。
我們設想構建一個可以提供比BPF更高層的接口庫，以及新的BPF鉤子，且盡可能早于存儲I/O completion路徑(類似XDP)[21]。該庫可能包含用于加速訪問和操作特定數據結構的BPF函數，如B樹和日志結構合并樹(LSM)。
在內核中，在每個塊I/O結束后，NVMe驅動中斷處理器可能會觸發這些BPF函數。通過給予這些函數訪問塊數據原始緩沖的功能，可以從存儲的塊中抽取文件偏移，并立即使用這些偏移發起I/O。它們還可以通過后續返回給應用的緩沖來過濾、投影和匯總塊數據。通過將應用定義的數據結構推送到內核，這些函數可以在應用有限參與的情況下遍歷持久化數據結構。與XN不同，XN目的是實現完整的系統，而這些存儲BPF函數主要是為了定義構成應用數據結構的存儲塊布局。
我們概括了初步設計中需要關注的主要考量點和挑戰，我們相信通過這種方式可以實現目標，而無需對Linux內核進行實質性的重構。
安裝&執行。為了加速相關訪問，我們的庫使用一個特殊的ioctl安裝了一個BPF函數。安裝后，會對應用發起I/O時使用的文件描述符"打標簽"(tagged)，傳遞到NVMe層時也會攜帶該標簽，后續會在觸發NVMe設備中斷處理器的內核I/O completion路徑上檢查該標簽。對于每個打標簽的submission/completion請求，我們的NVMe中斷處理器鉤子會將讀存儲塊傳遞到BPF函數中。
當觸發鉤子時，BPF函數可以執行一部分工作。例如，它可以從塊中抽取文件偏移，可以通過調用輔助函數來"回收"NVMe提交描述符和I/O緩沖，將描述符重新定位到新的偏移并將其重新發布到NVMe設備提交隊列。因此，一個I/O completion可以決定下一個可以提交的I/O，而無需分配額外的CPU或延時。這類函數可以在沒有應用層參與的情況下快速遍歷結構。
這些函數也可以將塊緩沖中的數據拷貝或聚合到本地緩沖中，使得函數可以通過執行選擇、投影或聚合來生成返回到應用程序的結果。當函數結束時，它可以指定返回給應用的緩沖。如果函數啟動了一個新的I/O，且還沒有將結果返回給應用時(例如還沒有找到正確的塊)，則無需返回任何緩沖，這樣可以防止將I/O完成上升到應用層。
轉換&安全。在Linux中，NVMe驅動無法訪問文件系統元數據。如果在一個文件的o1偏移處完成了一個I/O，BPF函數可能會使用偏移量o2來發起下一個I/O。由于NVMe無法判斷該偏移量對應哪個物理塊，因此o2毫無意義。塊可以嵌入物理塊地址來避免查詢擴展區，但由于沒有對這些地址進行限制，BPF函數可以訪問設備上的任意塊。因此，一個重要的挑戰是向NVMe層提供足夠的信息，有效安全地將文件偏移映射到文件對應的相應物理塊偏移，而不會限制文件系統重映射(選擇的)塊的能力。
為了簡化設計和保證安全性，每個函數僅會使用附加的ioctl用到的文件的偏移量。通過這種方式保證函數不會訪問不屬于該文件的數據。為了在實現該目的的同時不會減緩文件系統層的調用，且不會限制文件系統層的塊分配策略，我們打算在在文件的extents(與ext4文件系統有關)不變時觸發該塊的回收。我們觀察到，很多數據中心應用并不會原地修改塊存儲上的持久化結構。例如，一旦一個LSM樹將SSTable文件寫入磁盤，則這些文件就不會變且extents是穩定的[26]。在運行TokuDB的MariaDB上進行24小時的YCSB [25]（讀取40％，更新40％，插入20％，Zip為0.7）實驗，發現索引文件的extents平均每159秒才會進行一次變更，而24小時內只有5個extents的變更沒有映射任何塊。注意，在這些索引的實現中，每個索引保存在一個文件中，且不會跨多個文件，這種存儲方式可以簡化我們的設計。
我們通過NVMe層extents的軟狀態緩存來獲得文件extents的相對穩定性。當ioctl首次在存儲數據結構的文件上安裝功能時，文件的extents會傳遞到NVMe層。如果存在沒有映射到塊的文件extents，則文件系統中的新鉤子會向NVMe層觸發一個無效調用，丟棄正在回收的I/O，并向應用層返回一個錯誤，必須重新運行ioctl才能重置NVMe層extents，然后才能重新發出帶標簽的I/O。這是一種笨拙但簡單的方法，幾乎完全將文件系統和NVMe層進行了解耦，且沒有對文件系統塊分配策略施加任何限制。當然，為了有效利用緩存，必須減少這類無效調用。
I/O粒度不匹配。當BIO層"分割"一個I/O時(如跨兩個不連續的擴展)，會在不同的時間產生多個NVMe操作。我們期望盡量減少這類情況，這樣就可以像一個普通BIO那樣執行I/O，并將緩沖和completion返回給應用。這里，它可以執行BPF函數，并在內核開始下一次"hop"時重啟I/O鏈，這樣可以避免額外的內核復雜性。類似地，如果應用需要生成更多的I/O來響應一個I/O completion，我們可以將該completion傳播到BIO層，在該層可以分配并將多個I/O提交到NVMe層，以此來避免返回給應用層。
Cache。由于索引的緩存通常由應用程序來管理[14, 23, 26]，我們假設BPF遍歷時不會直接與緩沖區緩存進行交互，應用管理緩存并與遍歷保持同步。緩存驅逐和管理越來越多地以具有應用程序意義的對象粒度(如，單個數據記錄)為單位而非以整個分頁為單位進行處理。我們的方案會符合這些模型，BPF可以將特定的對象返回給應用(而不是分頁)，這樣應用就可以采納自己的緩存策略。
并發性和公平性。從文件系統發起的寫可能只會反應在緩沖區緩存中，BPF遍歷不可見。可以通過鎖定來解決這個問題，但從NVMe驅動程序內部來管理應用程序級別的鎖定可能會很昂貴。因此，需要精心設計需要細粒度鎖定的數據結構(例如B +樹中的鎖定耦合[28])。
為了避免讀/寫沖突，一開始我們計劃使用不可變的數據結構(至少是一段時間不可變)。幸運的是，很多數據結構都具有這種特性，包括LSM SSTable文件(不可變[26,39])，以及磁盤B樹，它們不會原地動態更新，而是會分批處理[14]。此外，由于鎖的復雜性，我們計劃一開始只支持只讀的BPF遍歷。
BPF發起的請求不會經過文件系統或塊層，因此不容易在進程間保證公平性或QoS，但由于NVMe設備默認的Linux塊層調度器是noop，且NVMe規范支持在需要公平性時，在硬件隊列使用命令仲裁[11]。另一個挑戰是，NVMe層可能會無限發起I/O請求。eBPF校驗器會阻止無界循環[38]，但我們也需要阻止NVMe鉤子上的無界I/O循環。
為了實現公平性，并防止無界遍歷，我們計劃在NVMe層為每個進行實現一個計數器，跟蹤I/O調用鏈提交的數目，并在計數器上設置一個邊界。計數器的值會周期性地傳遞給BIO層，統計請求數目。
總結
BPF有提升高速存儲設備的相關查找速度的潛力。但同時也產生了相應的挑戰，特別是由于丟失上下文，對操作內核底層存儲棧增加了難度。本論文中，我們主要關注索引遍歷。即便如此，對于現在的高速NVMe設備，通過使用BPF將少量請求串接起來也可以獲得顯著的收益。我們可以預想到，BPF存儲庫可以為開發者在其他標準內核存儲操作中提供便利，如壓縮(compaction，compression)，重復數據刪除和掃描。我們也相信BPF與緩存和調度器策略的交互也會創造令人興奮的研究機會。
引用
[1] 200Gb/s ConnectX-6 Ethernet Single/DualPort Adapter IC | NVIDIA. https: //www.mellanox.com/products/ ethernet-adapter-ic/connectx6-en-ic.
[2] bcc. https://github.com/iovisor/ bcc.
[3] bpftrace. https://github.com/ iovisor/bpftrace.
[4] Cilium. https://github.com/cilium/ cilium.
[5] Cloudflare architecture and how BPF eats the world. https://blog.cloudflare.com/ cloudflare-architecture-and-howbpf-eats-the-world/.
[6] eBPF. https://ebpf.io/.
[7] Effocient io with io_uring. https: //kernel.dk/io_uring.pdf.
[8] Intel? Optane? SSD DC P5800X Series. https://ark.intel.com/content/ www/us/en/ark/products/201859/ intel-optane-ssd-dc-p5800xseries-1-6tb-2-5in-pcie-x4-3dxpoint.html.
[9] MAC and Audit policy using eBPF. https:// lkml.org/lkml/2020/3/28/479.
[10] Ngd systems newport platform. https: //www.ngdsystems.com/technology/ computational-storage.
[11] NVMe base specification. https: //nvmexpress.org/wp-content/ uploads/NVM-Express-1_4b2020.09.21-Ratified.pdf.
[12] Open-sourcing katran, a scalable network load balancer. https://engineering.fb.com/ 2018/05/22/open-source/opensourcing-katran-a-scalablenetwork-load-balancer/.
[13] Optimizing Software for the Next Gen Intel Optane SSD P5800X. https://www.intel.com/ content/www/us/en/events/ memory-and-storage.html?videoId= 6215534787001.
[14] Percona tokudb. https:// www.percona.com/software/mysqldatabase/percona-tokudb.
[15] RocksDB iterator. https://github.com/ facebook/rocksdb/wiki/Iterator.
[16] SmartSSD computational storage drive. https: //www.xilinx.com/applications/ data-center/computationalstorage/smartssd.html.
[17] SQL server index architecture and design guide. https://docs.microsoft.com/en-us/ sql/relational-databases/sqlserver-index-design-guide.
[18] A thorough introduction to eBPF. https:// lwn.net/Articles/740157/.
[19] Toshiba memory introduces XL-FLASH storage class memory solution. https: //business.kioxia.com/en-us/news/ 2019/memory-20190805-1.html.
[20] Ultra-Low Latency with Samsung Z-NAND SSD. https:// www.samsung.com/semiconductor/ global.semi.static/UltraLow_Latency_with_Samsung_ZNAND_SSD-0.pdf.
[21] XDP. https://www.iovisor.org/ technology/xdp.
[22] Adam Belay, George Prekas, Ana Klimovic, Samuel Grossman, Christos Kozyrakis, and Edouard Bugnion. IX: A protected dataplane operating system for high throughput and low latency. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), pages 49–65, Broomeld, CO, October 2014. USENIX Association.
[23] Badrish Chandramouli, Guna Prasaad, Donald Kossmann, Justin Levandoski, James Hunter, and Mike Barnett. FASTER: A concurrent key-value store with in-place updates. In Proceedings of the 2018 International Conference on Management of Data, SIGMOD ’18, page 275–290, New York, NY, USA, 2018. Association for Computing Machinery.
[24] J Chao. Graph databases for beginners: Graph search algorithm basics. https: //neo4j.com/blog/graph-searchalgorithm-basics/.
[25] Brian F Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears. Benchmarking cloud serving systems with YCSB. In Proceedings of the 1st ACM symposium on Cloud computing, pages 143–154, 2010.
[26] Siying Dong, Mark Callaghan, Leonidas Galanis, Dhruba Borthakur, Tony Savor, and Michael Strum. Optimizing space amplification in rocksdb. In CIDR, volume 3, page 3, 2017.
[27] Pekka Enberg, Ashwin Rao, and Sasu Tarkoma. Partition-aware packet steering using XDP and eBPF for improving application-level parallelism. In Proceedings of the 1st ACM CoNEXT Workshop on Emerging In-Network Computing Paradigms, ENCP ’19, page 27–33, New York, NY, USA, 2019. Association for Computing Machinery.
[28] Goetz Graefe. A Survey of B-Tree Locking Techniques. ACM Transactions on Database Systems, 35(3), July 2010.
[29] Brendan Gregg. BPF Performance Tools. AddisonWesley Professional, 2019.
[30] Toke H?iland-J?rgensen, Jesper Dangaard Brouer, Daniel Borkmann, John Fastabend, Tom Herbert, David Ahern, and David Miller. The express data path: Fast programmable packet processing in the operating system kernel. In Proceedings of the 14th international conference on emerging networking experiments and technologies, pages 54–66, 2018.
[31] Stratos Idreos, Niv Dayan, Wilson Qin, Mali Akmanalp, Sophie Hilgard, Andrew Ross, James Lennon, Varun Jain, Harshita Gupta, David Li, et al. Design continuums and the path toward selfdesigning key-value stores that know and learn. In CIDR, 2019.
[32] M. Frans Kaashoek, Dawson R. Engler, Gregory R. Ganger, Hector M. Brice?o, Russell Hunt, David Mazières, Thomas Pinckney, Robert Grimm, John Jannotti, and Kenneth Mackenzie. Application Performance and Flexibility on Exokernel Systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles, SOSP ’97, page 52–65, New York, NY, USA, 1997. Association for Computing Machinery.
[33] Kostis Kaffes, Timothy Chong, Jack Tigar Humphries, Adam Belay, David Mazières, and Christos Kozyrakis. Shinjuku: Preemptive scheduling for μsecond-scale tail latency. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), pages 345–360, 2019.
[34] Anuj Kalia, Michael Kaminsky, and David Andersen. Datacenter RPCs can be general and fast. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), pages 1–16, Boston, MA, February 2019. USENIX Association.
[35] Kornilios Kourtis, Animesh Trivedi, and Nikolas Ioannou. Safe and Efficient Remote Application Code Execution on Disaggregated NVM Storage with eBPF. arXiv preprint arXiv:2002.11528, 2020.
[36] Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Hariharan Gopalakrishnan, Andrea C ArpaciDusseau, and Remzi H Arpaci-Dusseau. Wisckey: Separating keys from values in ssd-conscious storage. ACM Transactions on Storage (TOS), 13(1):1–28, 2017.
[37] Michael Marty, Marc de Kruijf, Jacob Adriaens, Christopher Alfeld, Sean Bauer, Carlo Contavalli, Mike Dalton, Nandita Dukkipati, William C. Evans, Steve Gribble, Nicholas Kidd, Roman Kononov, Gautam Kumar, Carl Mauer, Emily Musick, Lena Olson, Mike Ryan, Erik Rubow, Kevin Springborn, Paul Turner, Valas Valancius, Xi Wang, and Amin Vahdat. Snap: a microkernel approach to host networking. In In ACM SIGOPS 27th Symposium on Operating Systems Principles, New York, NY, USA, 2019.
[38] Luke Nelson, Jacob Van Geffen, Emina Torlak, and Xi Wang. Specification and verification in the field: Applying formal methods to BPF just-in-time compilers in the linux kernel. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20), pages 41–61. USENIX Association, November 2020.
[39] Patrick O’Neil, Edward Cheng, Dieter Gawlick, and Elizabeth O’Neil. The log-structured merge-tree (lsm-tree). Acta Informatica, 33(4):351–385, 1996.
[40] Weikang Qiao, Jieqiong Du, Zhenman Fang, Michael Lo, Mau-Chung Frank Chang, and Jason Cong. High-throughput lossless compression on tightly coupled CPU-FPGA platforms. In 2018 IEEE 26th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM), pages 37–44. IEEE, 2018.
[41] Zhenyuan Ruan, Tong He, and Jason Cong. INSIDER: Designing in-storage computing system for emerging high-performance drive. In 2019 USENIX Annual Technical Conference (USENIX ATC 19), pages 379–394, 2019.
[42] Sudharsan Seshadri, Mark Gahagan, Sundaram Bhaskaran, Trevor Bunker, Arup De, Yanqin Jin, Yang Liu, and Steven Swanson. Willow: A userprogrammable SSD. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), pages 67–80, Broomeld, CO, October 2014. USENIX Association.
[43] Shin-Yeh Tsai and Yiying Zhang. Lite kernel RDMA support for datacenter applications. In Proceedings of the 26th Symposium on Operating Systems Principles, pages 306–324, 2017.
[44] Ziye Yang, James R Harris, Benjamin Walker, Daniel Verkamp, Changpeng Liu, Cunyin Chang, Gang Cao, Jonathan Stern, Vishal Verma, and Luse E Paul. SPDK: A development kit to build high performance storage applications. In 2017 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), pages 154–161. IEEE, 2017.
[45] Irene Zhang, Jing Liu, Amanda Austin, Michael Lowell Roberts, and Anirudh Badam. I’m not dead yet! the role of the operating system in a kernel-bypass era. In Proceedings of the Workshop on Hot Topics in Operating Systems, pages 73–80, 2019.
