性能不精確的調用圖報告

Question

最近的 Intel 處理器提供了一個硬件功能（又名， Precise Event-Based Sampling (PEBS) ）來訪問有關 CPU state 在某些采樣 CPU 事件（例如， e ）上的精確信息。 這是英特爾 64 和 IA-32 架構的軟件開發人員手冊：第 3 卷的摘錄：

18.15.7 處理器基於事件的采樣（PEBS）

基於英特爾 NetBurst 微架構的處理器中的調試存儲 (DS) 機制允許收集兩種類型的信息以用於調試和調整程序：PEBS 記錄和 BTS 記錄。

基於同一參考文獻的Chapter 17 ， x86-64架構的 DS 格式如下： BTS Buffer記錄最后N個執行的分支（ N取決於微架構），而PEBS Buffer記錄以下寄存器： IIUC，設置了一個計數器，每個事件 ( e ) 的發生都會增加它的值。 當計數器溢出時，將向這兩個緩沖區添加一個條目。 最后，當這些緩沖區達到一定大小（ BTS Absolute Maximum和PEBS Absolute Maximum ）時，會產生中斷，並將兩個緩沖區的內容轉儲到磁盤。 這會定期發生。 似乎--call-graph dwarf回溯數據也是在同一個處理程序中提取的，對吧？

1) 這是否意味着LBR和PEBS ( --call-graph --lbr ) state 完美匹配？

2) --call-graph dwarf output 怎么樣，它不是PEBS的一部分（在上述參考中似乎很明顯）？ （某些RIP/RSP與回溯不匹配）

准確地說，這是一個LKML Thread ，其中Milian Wolff表明第二個問題是NO 。 但我不完全明白原因？

第一個問題的答案也是， NO （由Andi Kleen在線程的后面消息中表示），我完全不明白。

3）這是否意味着整個DWARF調用圖信息已完全損壞？

上面的線程沒有顯示這一點，在我的實驗中，我沒有看到任何與回溯不匹配的RIP 。 換句話說，我可以相信大多數回溯嗎？

我不喜歡LBR方法，它本身可能不精確。 它還受限於回溯的大小。 雖然， 這是一個克服尺寸問題的補丁。 但這是最近的，可能是假的。

---

更新：

• 如何強制Perf在PEBS Buffer中僅存儲一條記錄？ 是否只能間接強制這種配置，例如，當PEBS事件需要調用圖信息時？

Answer 1

1. 您引用的手冊部分談論的是 BTS，而不是 LBR：它們不是一回事。 稍后在您引用的同一線程中， Andi Kleen 似乎表明 LBR 快照時間實際上是 PMI（運行處理程序的中斷）的時刻，而不是 PEBS 時刻。 所以我認為所有三種堆棧方法都有相同的問題。

2. DWARF 堆棧捕獲肯定與 PEBS 條目不完全對應。 PEBS 事件在運行時由硬件記錄，然后僅在一段時間后 CPU 中斷，此時堆棧被展開。 如果 PEBS 緩沖區被配置為只保存一個條目，那么這兩個東西至少應該接近，如果幸運的話，PEBS IP 將位於處理程序運行時仍在堆棧頂部的相同 function中。 在那種情況下，堆棧基本上是正確的。 由於perf在頂部向您顯示了實際的 PEBS IP，再加上捕獲的幀下方的幀，因此在這種情況下最終可以正常工作。

3. 如果您不走運，function 將在 PEBS 捕獲和處理程序運行之間發生變化。 在這種情況下，您會得到一個沒有意義的 franken 堆棧：頂部 function 可能無法從第二個從頂部 function （或其他東西）調用。 它並沒有完全損壞：只是除了頂部幀之外的所有內容都來自捕獲 PEBS 堆棧之后的某個點，而頂部幀來自 PEBS 或類似的東西。 出於同樣的原因，這也適用於--call-graph fp 。

很可能您從未見過無效的 IP，因為perf顯示了 PEBS 示例中的 IP（這是整個線程的主題）。 我想如果你查看原始樣本，你可以看到 PEBS IP 和處理程序 IP，你可以看到它們通常不匹配。

總體而言，您可以相信“時間”或“周期”分析的回溯，因為它們在某種意義上是執行時間的准確采樣表示：只是它們不對應於 PEBS 時刻，而是一段時間后（但為什么以后的時間比 PEBS 時間差）。 基本上，對於這種類型的分析，您根本不需要 PEBS。

如果您使用的是不同類型的事件，並且您希望對事件發生的位置進行細粒度的記賬，那么這就是 PEBS 的用途。 您通常不需要堆棧跟蹤：只需頂部框架就足夠了。 如果您想要堆棧跟蹤，請使用它們，但要知道它們來自稍后的某個時刻，或者使用--lbr (if that works) 。