BPF for storage：一種受外核啟發的反式
譯自：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中斷處理器內部。但這也為使用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.