LWN：用BPF異步采集stack trace！

關(guān)注了就能看到更多這么棒的文章哦～

Capturing stack traces asynchronously with BPF

By Daroc Alden
June 19, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/978736/

Andrii Nakryiko 在 2024 年的 Linux 存儲、文件系統(tǒng)、內(nèi)存管理和 BPF 峰會 (Linux Storage, Filesystem, Memory Management, and BPF Summit) 上主持了一場會議，介紹了使用 BPF 捕獲堆棧跟蹤的 API，以及如何使這些 API 更實(shí)用。BPF 程序可以捕獲正在運(yùn)行的進(jìn)程的當(dāng)前堆棧跟蹤（stack trace），包括系統(tǒng)調(diào)用執(zhí)行中位于內(nèi)核的部分，這對于診斷性能問題等非常有用。但現(xiàn)有的 API 存在一些重大問題。

獲取 BPF 中堆棧跟蹤的現(xiàn)有方法是創(chuàng)建一個(gè)用于保存 trace 的元素的 BPF 映射（map），然后從 BPF 端調(diào)用 bpf_get_stackid() ，該函數(shù)返回此映射的唯一 ID，Nakryiko 解釋道。然后，在用戶空間中，程序可以進(jìn)行正常的映射查找從而來檢索堆棧跟蹤。內(nèi)核還捕獲并存儲一些相關(guān)信息，例如 ELF 構(gòu)建 ID 和文件偏移量，這有助于確定堆棧跟蹤對應(yīng)于哪個(gè)程序，以便進(jìn)行離線分析。他表示，這個(gè) API 聽起來相當(dāng)簡單，但不幸的是它有一些麻煩之處。

它可以捕獲用戶空間堆棧跟蹤或內(nèi)核堆棧跟蹤，但不能同時(shí)捕獲兩者。內(nèi)核支持捕獲兩者，只是 BPF API 無法表達(dá)出想同時(shí)要兩者，Nakryiko 說。此外，也無法知道實(shí)際捕獲的堆棧有多大；程序員只能希望他們的堆棧展開代碼在正確的位置停止。這都是缺陷，但不是大問題，因?yàn)闆]有人抱怨過。

最后一個(gè)麻煩是內(nèi)核會自動執(zhí)行堆棧去重。如果捕獲的堆棧跟蹤與現(xiàn)有的堆棧跟蹤匹配，內(nèi)核將返回現(xiàn)有 ID。這種行為在理論上聽起來很棒，因?yàn)槿ブ乜梢怨?jié)省空間，但用于存儲堆棧跟蹤的映射沒有處理哈希沖突的邏輯。堆棧跟蹤會被哈希并放置到映射中相應(yīng)的位置，但每個(gè)位置只能容納一個(gè)堆棧跟蹤。因此，哈希沖突（哈希相同但實(shí)際上 trace 內(nèi)容不同）在捕獲大量堆棧跟蹤時(shí)既頻繁又不可避免。API 允許程序員指定在沖突時(shí)保留舊堆棧跟蹤還是新堆棧跟蹤，但這只是給他們留下了兩個(gè)糟糕的選擇：丟失數(shù)據(jù)或損壞數(shù)據(jù)?；诠５亩褩Ｈブ剡€使得清除映射中的條目產(chǎn)生了天生的競爭沖突。

Nakryiko 提出的新 API 通過讓 BPF 程序處理內(nèi)存管理來解決這些問題：它提供一個(gè)緩沖區(qū)，內(nèi)核在其中捕獲堆棧跟蹤，然后 BPF 程序可以自由地以對應(yīng)用程序最有意義的方式與用戶空間共享該緩沖區(qū)。他指出，Meta 的所有用例（除一個(gè)外）都已切換到新的 API。但是，仍然有一些潛在的改進(jìn)空間。目前，堆棧是同步捕獲的。這是一個(gè)問題，因?yàn)?API 可以從任何地方調(diào)用，包括不允許出現(xiàn)頁面錯(cuò)誤（page fault）的上下文中。

如果正在檢查的程序的一部分被換出（paged out），這意味著存儲在這些頁面上的信息可能無法被采集到。這只會影響用戶空間堆棧跟蹤，因?yàn)閮?nèi)核始終保持在內(nèi)存中。這對使用基于 DWARF 的堆棧展開的程序來說是一個(gè)特殊問題，因?yàn)楫?dāng)進(jìn)行捕獲時(shí)，DWARF 調(diào)試信息不太可能存在于內(nèi)存中。

Nakryiko 希望新的 API 是異步的，以便它可以等待必要的（供用戶空間捕獲）信息被換入。但是，這對 /kernel/ 堆棧跟蹤不起作用，因?yàn)閮?nèi)核無法像用戶空間那樣暫停下來等待。另一方面，在內(nèi)核返回用戶空間之前，捕獲用戶空間堆棧跟蹤可以被推遲而不會改變返回的信息，因?yàn)檫M(jìn)程直到那時(shí)才會被凍結(jié)。他說，“返回用戶空間”是一個(gè)很好的上下文，因?yàn)閮?nèi)核可以等待內(nèi)存被換入等等。

所有這些單獨(dú)的約束在提出的 API 設(shè)計(jì)中被匯集起來。Nakryiko 建議使用一個(gè)函數(shù)返回堆棧跟蹤的唯一 ID。ID 就像是預(yù)留的一樣——它是穩(wěn)定的，可以被記錄、傳遞給用戶空間等等。一旦收到 ID，就會將堆棧跟蹤捕獲到保留的緩沖區(qū)中。內(nèi)核跟蹤是同步捕獲的，但用戶空間跟蹤是在返回用戶空間時(shí)捕獲的。在相應(yīng)映射中查找堆棧捕獲將返回 EAGAIN ，直到捕獲內(nèi)容準(zhǔn)備好。內(nèi)核不會執(zhí)行去重，使得刪除元素以一種合理的方式工作。一位觀眾詢問這是否意味著可能存在具有不同 ID 的相同堆棧跟蹤，Nakryiko 確認(rèn)情況確實(shí)如此。Daniel Borkmann 指出，如果操作是異步的，那么也可以擴(kuò)展映射本身，而現(xiàn)有的 API 無法做到這一點(diǎn)。

Nakryiko 說，API 的一部分還沒有想好：如何讓用戶知道堆棧跟蹤何時(shí)準(zhǔn)備好。他說，最簡單的解決方案是不發(fā)送通知，而是強(qiáng)制用戶輪詢。稍微復(fù)雜一些的是，每當(dāng)任何跟蹤準(zhǔn)備好時(shí)，都會發(fā)出映射范圍的 epoll 通知?；蛘?，映射中的每個(gè)槽位都可以有單獨(dú)的 epoll 通知——但這將是浪費(fèi)文件描述符。最后，最有效的方法是建立一個(gè) BPF 環(huán)形緩沖區(qū)，將 ID 放入其中，以便在它們準(zhǔn)備好時(shí)進(jìn)行有效的通知和消費(fèi)。

一位觀眾指出，Nakryiko 基本上描述了 io_uring 背后的機(jī)制，并建議說這可能是最合適的機(jī)制。Nakryiko 對 io_uring 是否適合不太確定，但承認(rèn)了這種可能性。另一位觀眾詢問他們是否可以將可擴(kuò)展的環(huán)形緩沖區(qū)放入 BPF arena 中。Nakryiko 認(rèn)為這不會有幫助，因?yàn)?BPF 子系統(tǒng)中已經(jīng)有很多環(huán)形緩沖區(qū)，在 arena 中重新實(shí)現(xiàn)一個(gè)不會真正起到幫助。他確實(shí)注意到，如果他們切換到將整個(gè)堆棧跟蹤放入環(huán)形緩沖區(qū)，他們就可以在環(huán)形緩沖區(qū)中包含丟棄通知（drop notification）。

Yu 指出，API 可以使用回調(diào)而不是通知：在完成時(shí)運(yùn)行另一個(gè) BPF 程序，并讓用戶決定如何通知用戶空間。這引發(fā)了關(guān)于不同機(jī)制的長時(shí)間討論，以及它們?nèi)绾卧陟`活性與簡單性之間權(quán)衡。Nakryiko 確實(shí)說他不贊成試圖將太多功能從內(nèi)核中移出的機(jī)制，因?yàn)閮?nèi)核已經(jīng)對堆棧跟蹤有良好的內(nèi)置支持。一個(gè)例子是用戶空間返回探測如何破壞堆棧跟蹤——內(nèi)核擁有所有必要的信息來修復(fù)這個(gè)問題，而更靈活的機(jī)制只會把這個(gè)工作推給用戶。

在會議時(shí)間結(jié)束之前，討論沒有得出明確的結(jié)論，但內(nèi)核中 BPF 及其他地方已經(jīng)有很多機(jī)制用于在操作完成時(shí)通知用戶空間，因此這似乎不太可能成為 API 設(shè)計(jì)的癥結(jié)所在?？紤]到 BPF 與 BPF 類型格式 (BTF, BPF Type Format) 的緊密集成以及對內(nèi)核和用戶空間中跟蹤點(diǎn)（tracepoints）的支持，BPF 已經(jīng)具有相當(dāng)好的調(diào)試支持；看起來一些正在進(jìn)行的工作可以幫助進(jìn)一步擴(kuò)展這種支持。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～